RE: Issue 83: CUI and re-authentication

["Adrangi, Farid" <farid.adrangi@intel.com>]

No. The "Validation" means that the RADIUS server checks to see if the
CUI value is the same as the one that was sent in the previous
Access-Accept.   However, the RADIUS server does not require to do this
validation.
Thanks,
Farid

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Monday, April 25, 2005 6:50 PM
> To: Adrangi, Farid
> Cc: radiusext@ops.ietf.org; Nelson, David
> Subject: RE: Issue 83: CUI and re-authentication
> 
> 
> Presumably, by "validated" you mean that the CUI presented is 
> associated
> with the subsequently authenticated identity.
> 
> On Mon, 25 Apr 2005, Adrangi, Farid wrote:
> 
> > Good point Bernard!  Avi and I just discussed this, and our current
> > thinking is to add something like below to the draft:
> >
> > "
> > When re-authenticating, a NAS that supports CUI MUST include the CUI
> > attribute with the value of CUI received in a previous 
> Access-Accept.
> >
> > Upon receiving a non-nul CUI in an Access-Request the home 
> RADIUS server
> > MAY validate the value of CUI and if the validation fails, then the
> > RADIUS server SHOULD respond with an Access-Reject message.
> >
> > During reauthentication, upon receiving an Access-Accept, 
> the value of
> > the CUI maybe different from the previously received CUI for that
> > session. The NAS MUST use this value on all subsequent accounting
> > messages for that session.
> > "
> >
> > Does this work for you, all?
> >
> > Thanks,
> > Farid
> >
> > > -----Original Message-----
> > > From: owner-radiusext@ops.ietf.org
> > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> > > Sent: Friday, April 22, 2005 7:33 PM
> > > To: radiusext@ops.ietf.org
> > > Subject: Issue 83: CUI and re-authentication
> > >
> > >
> > > Issue 83: CUI and re-authentication
> > > Submitter name: Bernard Aboba
> > > Submitter email address: aboba@internaut.com
> > > Date first submitted: April 22, 2005
> > > Reference:
> > > Document: CUI-04
> > > Comment type: T
> > > Priority: S
> > > Section: Various
> > > Rationale/Explanation of issue:
> > >
> > > The document does not state how CUI is used with an
> > > Access-Request that
> > > occurs due to re-authentication.  For example, in the original
> > > authentication, the CUI attribute was provided within the
> > > Access-Accept,
> > > and subsequently within Accounting-Request packets 
> (interim).  Let us
> > > assume that a Session-Timeout attribute was sent with
> > > Termination-Action=RADIUS.
> > >
> > > What happens at the expiration of the Session-Timeout value?
> > > Does the NAS
> > > send an Access-Request containing a CUI attribute to the 
> RADIUS server
> > > with the currently used CUI, or does it send an empty CUI
> > > attribute?  It
> > > seems more appropriate for it to send the currently used CUI,
> > > since that
> > > does not require the RADIUS server to keep state.  I presume
> > > that the User-Name and EAP re-authentication elements are
> > > handled the same
> > > way (e.g. User-Name includes "@realm" privacy NAI).
> > >
> > > --
> > > 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/>
> > >
> >
> 

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