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

["Bernard Aboba" <bernard_aboba@hotmail.com>]

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 <lberger@movaz.com>
To: Bernard Aboba <aboba@internaut.com>
Cc: beckw@t-systems.com, lberger@labn.net
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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>