RADIUS Extension for Digest Authentication
RFC 4590

Note: This ballot was opened for revision 09 and is now closed.

(David Kessens) Yes

(Allison Mankin) Yes

(Brian Carpenter) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) (was Discuss) No Objection

(Scott Hollenbeck) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2005-12-15)
No email
send info
  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

  Section 4.20 says:
  >4.20.  SIP-AOR
  >   Type

  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@",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 (
  >    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?

(Cullen Jennings) No Objection

(Jon Peterson) (was Discuss, Yes) No Objection

Comment (2005-12-14)
No email
send info
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.

(Mark Townsley) (was Discuss) No Objection

Magnus Westerlund No Objection

(Bert Wijnen) No Objection

Comment (2005-12-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Page 26
      NAS-IP-Address = a 0 45 26 (
Probably IP address should be changed to be in accordance with
IP addresses for examples (RFC3330), i.e. range

(Alex Zinin) No Objection