Comments on draft-ietf-radext-digest-auth-06.txt (fwd)

["Bernard Aboba" <[e-mail]>]

RFC 3072 Section 1.1 talks about the requirements for RADIUS Digest 
Authentication:

   Nevertheless, a few limited RADIUS [5]
   extensions may meet some of the requirements in this document (for
   instance, some of the authentication requirements).  We expect that
   while RADIUS with these limited extensions will meet particular
   functional requirements, it will not meet other important
   requirements.  The following are some requirements that are not
   expected to be met by RADIUS:

      1. Section 2.1.3: RADIUS does not support a discovery feature.

      2. Section 2.1.7: RADIUS does not support reliable message
         delivery.

   The following list contains the requirements that can be met by
   RADIUS or RADIUS extensions.

      1. Section 2.1.2: Communication between domains does not scale
         well in RADIUS.  As a result, inter-domain communications are
         typically handled using a proxy architecture [6].

      2. Section 2.1.5: RADIUS clients would need to support Dynamic
         Authorization [7].

      3. Section 2.1.9: RADIUS clients would need to rely on a lower-
         layer security protocol, such as IPSec, to perform mutual
         authentication.

      4. Section 2.3.3: RADIUS clients would need to support Dynamic
         Authorization [7].

      5. Section 2.3.4: RADIUS clients would need to support Dynamic
         Authorization [7].



---------- Forwarded message ----------
Date: Wed, 16 Nov 2005 15:43:09 -0500
From: Lou Berger <[e-mail]>
To: Bernard Aboba <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Comments on draft-ietf-radext-digest-auth-06.txt

Bernard, (Wolfgang),

	Per our discussion in Vancouver, I've re-read
draft-ietf-radext-digest-auth-06.txt from the perspective of SIP 
authorization
and also comparing it to  draft-ietf-aaa-diameter-sip-app-10.txt.  I think 
you
were correct (and I wasn't) in the observation that the former does the job, 
but
I still have a small number of comments:

1.  It seems to me that both the SIP and Diameter drafts don't fully support 
the
requirements laid out in RFC 3702.  Also, neither draft references this RFC. 
  I
found this really surprising.  What is the relationship of the drafts to the
RFC?  Is there any intention/desire to have the drafts fully support it?  
I'm
sure I'm missing something, so what's the "big picture here"?

2. Here are some specific mismatches between the draft and RFC3702, please 
let
me know if I missed something.  Support for RFC 3702, section:
a) 2.1.5.  Updating SIP Server Entries (and missing reference to RFC 3576)
b) 2.3.2.  Information Transfer
	[I think this implies passing via & route information on the
authorization request as well as handling the response.]
c) 2.4.5.  Support for Accounting on Different Media

3. While not covered in the AAA requirements I think that authorization 
based on
requested media is also needed.  I think this is the complement of the 
(media
related) policy extensions being discussed within the SIPPING WG.

Please let me know what you think.

Much thanks,
Lou



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>