AW: Comments on draft-sterman-aaa-sip-03
"Beck01, Wolfgang" <BeckW@t-systems.com> Fri, 27 August 2004 13:40 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Fri, 27 Aug 2004 13:41:39 +0000
Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FD7D@E9JDF.mgb01.telekom.de>
From: "Beck01, Wolfgang" <BeckW@t-systems.com>
To: mccap@lucent.com, radiusext@ops.ietf.org
Subject: AW: Comments on draft-sterman-aaa-sip-03
Date: Fri, 27 Aug 2004 15:40:35 +0200
MIME-Version: 1.0
Content-Type: text/plain
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 section. 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 paragraph. > 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 > authentication. > 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? Proposal: "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 centrally. 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 attribute names. Proposal: "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 <IANA considerations>)." > Don't use text like "if this specification becomes a working group or IESG > document..." > [..] > Get rid of " Early implementations have used the experimental type > 206." Ok. 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 > security). > > 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 VPN. > 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 > IPSec? 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, Wolfgang -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>
- AW: Comments on draft-sterman-aaa-sip-03 Beck01, Wolfgang