Comments on draft-sterman-aaa-sip-03
Pete McCann <mccap@lucent.com> Thu, 26 August 2004 23:37 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Thu, 26 Aug 2004 23:38:43 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <16686.29740.890368.137984@gargle.gargle.HOWL>
Date: Thu, 26 Aug 2004 18:37:16 -0500
From: Pete McCann <mccap@lucent.com>
To: radiusext@ops.ietf.org
Subject: Comments on draft-sterman-aaa-sip-03
Hi, Attached are some review comments on draft-sterman-aaa-sip-03. -Pete 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): Change: lacking support, too: even two years To: lacking support, too; even two years Change: SIP service providers whishing To: SIP service providers wishing Section 1.5: Change: Section 1.4 describes an mechanism To: Section 1.4 describes a mechanism 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? 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. 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." 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 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? Maybe this paragraph is adequately covered by the security considerations (or should be) and could be deleted. -- 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/>
- Comments on draft-sterman-aaa-sip-03 Pete McCann