[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Protocol Action: 'RADIUS Extension for Digest Authentication' to Proposed Standard
The IESG has approved the following document:
- 'RADIUS Extension for Digest Authentication '
<draft-ietf-radext-rfc4590bis-02.txt> as a Proposed Standard
This document is the product of the RADIUS EXTensions Working Group.
The IESG contact persons are Dan Romascanu and Ron Bonica.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-02.txt
Technical Summary
This document defines an extension to the Remote Authentication Dial-
In User Service (RADIUS) protocol to enable support of Digest
Authentication, for use with HTTP-style protocols like the Session
Initiation Protocol (SIP) and HTTP.
Working Group Summary
Working Group discussion largely centered on whether the issues
identified in RFC 4590 could be fixed via an errata or whether
a new RFC was required. Due to conflicts between the RFC 4590 text
and the parameters allocated by IANA, it was decided that a new
RFC would be needed, so as to avoid potential interoperability
problems.
Protocol Quality
This document is needed to address a problem in the IANA allocations for
Digest Authentication as well as several errata that were found after the
publication of RFC 4590. This document is believed to address all issues
raised since the publication of RFC 4590. The document was reviewed by Dan
Romascanu on behalf of the IESG.
Note to RFC Editor
RFC Editor,
Please replace Appendix A with the text below:
This is an example selected from the traffic between a softphone (A),
a Proxy Server (B), and an example.com RADIUS server (C). The
communication between the Proxy Server and a SIP Public Switched
Telephone Network (PSTN) gateway is omitted for brevity. The SIP
messages are not shown completely.
The password of user '12345678' is 'secret'. The shared secret
between RADIUS client and server is 'secret'. To ease testing,
only the last byte of the RADIUS authenticator changes between
requests. In a real implementation, this would be a serious flaw.
A->B
INVITE sip:97226491335@example.com SIP/2.0
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com>
B->A
SIP/2.0 100 Trying
B->C
Code = Access-Request (1)
Packet identifier = 0x7c (124)
Length = 97
Authenticator = F5E55840E324AA49D216D9DBD069807C
NAS-IP-Address = 192.0.2.38
NAS-Port = 5
User-Name = 12345678
Digest-Method = INVITE
Digest-URI = sip:97226491335@example.com
Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B
C->B
Code = Access-challenge (11)
Packet identifier = 0x7c (124)
Length = 72
Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D
Digest-Nonce = 3bada1a0
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3
B->A
SIP/2.0 407 Proxy Authentication Required
Proxy-Authenticate: Digest realm="example.com"
,nonce="3bada1a0",qop=auth,algorithm=MD5
Content-Length: 0
A->B
ACK sip:97226491335@example.com SIP/2.0
A->B
INVITE sip:97226491335@example.com SIP/2.0
Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0"
,realm="example.com"
,response="7679b84a560835846ec553174dbabb69"
,uri="sip:97226491335@example.com",username="12345678"
,qop=auth,algorithm=MD5
,cnonce="56593a80,nc="00000001"
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com>
B->C
Code = Access-Request (1)
Packet identifier = 0x7d (125)
Length = 221
Authenticator = F5E55840E324AA49D216D9DBD069807D
NAS-IP-Address = 192.0.2.38
NAS-Port = 5
User-Name = 12345678
Digest-Method = INVITE
Digest-URI = sip:97226491335@example.com
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Digest-CNonce = 56593a80
Digest-Nonce = 3bada1a0
Digest-Nonce-Count = 00000001
Digest-Response = 7679b84a560835846ec553174dbabb69
Digest-Username = 12345678
SIP-AOR = sip:12345678@example.com
Message-Authenticator = BD037498E8385878A46ECF4D5F8D2B48
C->B
Code = Access-Accept (2)
Packet identifier = 0x7d (125)
Length = 72
Authenticator = 36E1201AD4377664E720184CE7B3D8C6
Digest-Response-Auth = 3792d3109224eb67213659e2d789f10d
Message-Authenticator = 9B79B410CEBD335176DAEB24735DCF64
B->A
SIP/2.0 180 Ringing
B->A
SIP/2.0 200 OK
A->B
ACK sip:97226491335@example.com SIP/2.0
A second example shows the traffic between a web browser (A), web
server (B), and a RADIUS server (C).
A->B
GET /index.html HTTP/1.1
B->C
Code = Access-Request (1)
Packet identifier = 0x7e (126)
Length = 68
Authenticator = F5E55840E324AA49D216D9DBD069807E
NAS-IP-Address = 192.0.2.38
NAS-Port = 5
Digest-Method = GET
Digest-URI = /index.html
Message-Authenticator = 690BFC95E88DF3B185F15CD78E469992
C->B
Code = Access-challenge (11)
Packet identifier = 0x7e (126)
Length = 72
Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E
Digest-Nonce = a3086ac8
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A
B->A
HTTP/1.1 401 Authentication Required
WWW-Authenticate: Digest realm="example.com",
nonce="a3086ac8",qop=auth,algorithm=MD5
Content-Length: 0
A->B
GET /index.html HTTP/1.1
Authorization: Digest algorithm=MD5,qop=auth,nonce="a3086ac8"
,nc="00000001",cnonce="56593a78"
,realm="example.com"
,response="ba623217b5ec024d30c4aaef9d8494de"
,uri="/index.html",username="12345678"
B->C
Code = Access-Request (1)
Packet identifier = 0x7f (127)
Length = 176
Authenticator = F5E55840E324AA49D216D9DBD069807F
NAS-IP-Address = 192.0.2.38
NAS-Port = 5
User-Name = 12345678
Digest-Method = GET
Digest-URI = /index.html
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Digest-CNonce = 56593a80
Digest-Nonce = a3086ac8
Digest-Nonce-Count = 00000001
Digest-Response = ba623217b5ec024d30c4aaef9d8494de
Digest-Username = 12345678
Message-Authenticator = C360BFCEDFFBCE893469E802013DA5AA
C->B
Code = Access-Accept (2)
Packet identifier = 0x7f (127)
Length = 72
Authenticator = F1ECAC22D3C88E0260B287FA35595F80
Digest-Response-Auth = 29624e0bee4342994d041d07f7bcd44c
Message-Authenticator = 956312EC57AF51ABC4F6965270F34982
B->A
HTTP/1.1 200 OK
...
<html>
...
--
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/>