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/>