[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-ietf-radext-digest-auth-06.txt (fwd)
RFC 3072 Section 1.1 talks about the requirements for RADIUS Digest
Nevertheless, a few limited RADIUS 
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
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 .
2. Section 2.1.5: RADIUS clients would need to support Dynamic
3. Section 2.1.9: RADIUS clients would need to rely on a lower-
layer security protocol, such as IPSec, to perform mutual
4. Section 2.3.3: RADIUS clients would need to support Dynamic
5. Section 2.3.4: RADIUS clients would need to support Dynamic
---------- Forwarded message ----------
Date: Wed, 16 Nov 2005 15:43:09 -0500
From: Lou Berger <email@example.com>
To: Bernard Aboba <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org
Subject: Comments on draft-ietf-radext-digest-auth-06.txt
Per our discussion in Vancouver, I've re-read
draft-ietf-radext-digest-auth-06.txt from the perspective of SIP
and also comparing it to draft-ietf-aaa-diameter-sip-app-10.txt. I think
were correct (and I wasn't) in the observation that the former does the job,
I still have a small number of comments:
1. It seems to me that both the SIP and Diameter drafts don't fully support
requirements laid out in RFC 3702. Also, neither draft references this RFC.
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?
sure I'm missing something, so what's the "big picture here"?
2. Here are some specific mismatches between the draft and RFC3702, please
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
requested media is also needed. I think this is the complement of the
related) policy extensions being discussed within the SIPPING WG.
Please let me know what you think.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.