[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: Comments on draft-sterman-aaa-sip-03
Pete McCann wrote:
> Document should start with an overview of the assumed architecture, as
> shown in e.g. Figure 1 of Section 1.3. However, the text of Section
> 1.3 dives into a particular scenario and a broader overview is
> necessary first. (I think Miguel made this comment earlier)
> Section 1.2 (although I think this text should be deleted):
When I started working on the draft, people asked for a motivational
I'll do an overview section which includes the 2 scenario sections
1.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Scenario 1, RADIUS client chooses nonces . . . . . . . 5
1.3.2 Scenario 2, RADIUS server chooses nonces . . . . . . . 6
Section 1.3 will be the '1.5 Approach' section of -03 without the last
> However, in
> some cases the RADIUS server is better off with pre-computed hashes.
> Section 1.4 describes an mechanism that enables this style of
> This paragraph mentions "precomputed hashes" but then the issue is never
> revisited. Is it true that precomputed hashes can be used with arbitrary
> message contents, or is some other coordination required between the
> home RADIUS server and the client?
"1.3.2 Scenario 2, RADIUS server chooses nonces
In most cases, the operation outlined in Section 1.3.1 is sufficient.
It reduces the load on the RADIUS server to a minimum. However, when
using AKA [RFC3310] the nonce is partially derived from a precomputed
authentication vector. These authentication vectors are often stored
Figure 3 depicts an scenario, where the RADIUS server chooses nonces."
> Section 2:
> Reformat list of attributes into a table, and use values like "TBD-DIG-RES"
> in the table. Create an IANA considerations section which requests allocations.
There is a IANA consideration section at the end of the document. I didn't want
to use DIG-RES etc. in the sub sections of 2. before explaining that they are
"2. New RADIUS attributes
DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG,
DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP,
DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that
are taken from the RADIUS attribute type number space (see Section
> Don't use text like "if this specification becomes a working group or IESG
> Get rid of " Early implementations have used the experimental type
The following is confusing:
> 3.1 RADIUS Client Behaviour
> A RADIUS client without an encrypted or otherwise secured connection
> to its RADIUS server only accepts unsecured connections from its
> HTTP-style clients (or else the clients would have a false sense of
> It is not quite clear what is meant by "encrypted or otherwise
> secured", because there are several different security mechanisms
> available in RADIUS, including the hop-by-hop message authenticator
> and the shared-key method of obfuscating individual attributes. I
"encrypted" ~ eg. IPSEC or proprietary tunnel technology
"otherwise secured" ~ eg. RADIUS client and server are in a closed MPLS
> assume this would not be adequate to provide the protection you are
> looking for. Also, what counts as an "unsecured connection" from an
> HTTP-style client? Do you mean one that doesn't use either TLS or
Yes. I'll insert a reference to the security considerations section,
which has this paragraph:
"HTTP-style clients can use TLS with server side certificates together
with HTTP-Digest authentication. IPSec can be used in a similar way.
TLS or IPSec secure the connection while Digest Authentication
authenticates the user. If a RADIUS client accepts such connections,
it MUST have a secure connection to the RADIUS server."
> Maybe this paragraph is adequately covered by the security
> considerations (or should be) and could be deleted.
I disagree. If a SIP client wants the signalling to be secure,
it uses sips: URLs. All SIP proxies along the way must use TLS
connections to forward requests with sips: URLs. I don't think
the SIP proxies (=RADIUS clients) should expose parts of the SIP
message by using a unencrypted RADIUS messages in this case.
As this is part of the client behaviour, I put it into that section.
Thank you very much for your help,
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.