Comments on draft-sterman-aaa-sip-03

[Pete McCann <mccap@lucent.com>]

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/>