Issue 196: User-Name Attribute
"Bernard Aboba" <bernard_aboba@hotmail.com> Sat, 03 June 2006 23:28 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Sat, 03 Jun 2006 23:29:17 +0000
Message-ID: <BAY106-F30091128FEA0D5F585837193960@phx.gbl>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: radiusext@ops.ietf.org
Bcc:
Subject: Issue 196: User-Name Attribute
Date: Sat, 03 Jun 2006 16:28:39 -0700
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"
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/>
- RE: Issue 196: User-Name Attribute Glen Zorn (gwz)
- RE: Issue 196: User-Name Attribute Bernard Aboba
- RE: Issue 196: User-Name Attribute Glen Zorn (gwz)
- RE: Issue 196: User-Name Attribute Bernard Aboba
- RE: Issue 196: User-Name Attribute Glen Zorn (gwz)
- Issue 196: User-Name Attribute Bernard Aboba