RADIUS Extension for Digest Authentication
RFC 4590
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
(Allison Mankin; former steering group member) Yes
(David Kessens; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
(Bert Wijnen; former steering group member) No Objection
Page 26
NAS-IP-Address = a 0 45 26 (10.0.69.38)
Probably IP address should be changed to be in accordance with
IP addresses for examples (RFC3330), i.e. 192.0.2.0/24 range
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) No Objection
(Cullen Jennings; former steering group member) No Objection
(Jon Peterson; former steering group member) (was Discuss, Yes) No Objection
The authors might note, contrary to impllication of the motivational text in 1.2, that RFC3261 did not intend to supplant Digest authentication with TLS and S/MIME. Digest is still mandatory and is the preferred way for a UA to authenticate itself to a proxy server. This just furthers the need for this mechanism, of course - the text in 1.2 makes it sound like Digest a legacy mechanism for SIP.
(Magnus Westerlund; former steering group member) No Objection
(Margaret Cullen; former steering group member) No Objection
(Mark Townsley; former steering group member) (was Discuss) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
Please include an informative reference for CHAP in section 1.3. Section 3.1 says: > > The RADIUS server MAY have added a Digest-Nextnonce attribute into an > Access-Accept packet. If the RADIUS client discovers this, it puts > the contents of this attribute into a 'nextnonce' directive. Now it > can send an HTTP-style response. > Perhaps a better wording might be: > > When the RADIUS server provides a Digest-Nextnonce attribute in the > Access-Accept packet, the RADIUS client puts the contexts of this > attribute into a 'nextnonce' directive so that it can send an > HTTP-style response. Section 4.9 says: > >4.9. Digest-Algorithm attribute > > Type > s/Type/Description/ Section 4.20 says: > >4.20. SIP-AOR > > Type > s/Type/Description/ Section 7 says: > > A->B > > INVITE sip:97226491335@example.com SIP/2.0 > Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" > ,opaque="",realm="example.com" > ,response="f3ce87e6984557cd0fecc26f3c5e97a4" > ,uri="sip:97226491335@10.0.69.38",username="12345678" > From: <sip:12345678@example.com> > To: <sip:97226491335@example.com> > > B->C > > Code = 1 (Access-Request) > Attributes: > NAS-IP-Address = a 0 45 26 (10.0.69.38) > NAS-Port-Type = 5 (Virtual) > User-Name = "12345678" > Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4" > Digest-Realm = "example.com" > Digest-Nonce = "3bada1a0" > Digest-Method = "INVITE" > Digest-URI = "sip:97226491335@example.com" > Why is the value of Digest-URI not the same URI provided by A?
(Sam Hartman; former steering group member) (was Discuss) No Objection
(Scott Hollenbeck; former steering group member) (was Discuss) No Objection
(Ted Hardie; former steering group member) No Objection