[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Issue 196: User-Name Attribute



Bernard Aboba <> supposedly scribbled:

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

Who cares?  I'm not being facetious: if the value is unknown by the client & unused by the server, why does it matter what the value is?
   
> 
> 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?   

The answer would be known if the questioner had been paying attention during the lengthy discussion of this issue; otherwise, it could be found in the archives.  I'm not sure why this qualifies as an "issue".

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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