[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposed Resolution to RFC 4590bis Issue 196
The text of issue 196 is enclosed below.
The issue here is that the second example (Web browser) seems to contract
the Attribute Table which indicates that a User-Name attribute is required
in an Access-Request containing a Digest-Method attribute. In the example,
no User-Name attribute is included.
Since RFC 2865 indicates that empty User-Name attributes can't be sent, one
possibility is for the Calling-Station-Id attribute to contain the users' IP
address, which would also be contained in the User-Name attribute.
There is also the question about what a server should do if a User-Name
attribute is not included in an Access-Request. Since the Attribute Table
indicates that the User-Name attribute is required, I think the answer is
that an Access-Reject is sent.
Finally, I would note that the examples do not include a realm within the
User-Name attribute, only the userid. Is this correct or should the
User-Name attribute contain 12345678@example.com?
The proposed resolution is as follows:
Change Section 6 to the following:
"6. Examples
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.
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 = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
User-Name = 12345678@example.com
Digest-Method = INVITE
Digest-URI = sip:97226491335@example.com
Message-Authenticator =
TBD
C->B
Code = 11 (Access-Challenge)
Attributes:
Digest-Nonce = 3bada1a0
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator =
f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40
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="f3ce87e6984557cd0fecc26f3c5e97a4"
,uri="sip:97226491335@example.com",username="12345678"
,qop=auth,algorithm=MD5
From: <sip:12345678@example.com>
To: <sip:97226491335@example.com>
B->C
Code = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
User-Name = 12345678@example.com
Digest-Response = f3ce87e6984557cd0fecc26f3c5e97a4
Digest-Realm = example.com
Digest-Nonce = 3bada1a0
Digest-Method = INVITE
Digest-URI = sip:97226491335@example.com
Digest-Qop = auth
Digest-Algorithm = md5
Digest-Username = 12345678
SIP-AOR = sip:12345678@example.com
Message-Authenticator =
TBD
C->B
Code = 2 (Access-Accept)
Attributes:
Digest-Response-Auth =
6303c41b0e2c3e524e413cafe8cce954
Message-Authenticator =
75 8d 44 49 66 1f 7b 47 9d 10 d0 2d 4a 2e aa f1
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 = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
Digest-Method = GET
Digest-URI = /index.html
Calling-Station-Id="192.168.1.20"
User-Name="192.168.1.20"
Message-Authenticator =
TBD
C->B
Code = 11 (Access-Challenge)
Attributes:
Digest-Nonce = a3086ac8
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator =
f8 01 26 9f 70 5e ef 5d 24 ac f5 ca fb 27 da 40
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,nonce="a3086ac8"
,realm="example.com"
,response="f052b68058b2987aba493857ae1ab002"
,uri="/index.html",username="12345678"
,qop=auth,algorithm=MD5
B->C
Code = 1 (Access-Request)
Attributes:
NAS-IP-Address = c0 0 2 26 (192.0.2.38)
NAS-Port-Type = 5 (Virtual)
User-Name = 12345678@example.com
Digest-Response = f052b68058b2987aba493857ae1ab002
Digest-Realm = example.com
Digest-Nonce = a3086ac8
Digest-Method = GET
Digest-URI = /index.html
Digest-Username = 12345678
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator =
TBD
C->B
Code = 2 (Access-Accept)
Attributes:
Digest-Response-Auth =
e644aa513effbfe1caff67103ff6433c
Message-Authenticator =
7a 66 73 a3 52 44 dd ca 90 e2 f6 10 61 2d 81 d7
B->A
HTTP/1.1 200 OK
...
<html>
..."
=========================
Issue 196: User-Name Attribute
Submitter names: Cristina Ruiz
Submitter email address: cristina.ruiz@ericsson.com
Date first submitted: June 2, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00527.html
Document: DIGEST-09
Comment type: 'T'echnical
Priority: S
Section: 5, 6
Rationale/Explanation of issue:
The User-Name attribute is mandatory in the RADIUS Access Request as
indicated in the table of attributes (Section 5). But in the initial HTTP
GET method, the user-name is not received, and in the example (Section 6)
nothing is sent in the User-name attribute in the B->C comunication. What
does the RADIUS client include in the User-Name attribute in this case? And
what shall the RADIUS Server do when this dummy user-name is received?
I think the "client nonce generation mode" removed from draft 07 was usefull
to avoid inventing a user name in this HTTP case (where the nonce
generation does not depend on the user and this is not received in the
initial request). Why was it removed?
--
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/>