[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 83: CUI and re-authentication
Hi John,
> 1) the CUI may change during reauthentication, but the home
> server doesn't need
> to check if it has changed.
The home network is the only entity that can change the value of the CUI.
Note that the value of the CUI is opaque to the NAS.
During reauthentication it may want to change the value of CUI. This could
happen because local policy states that change CUI on the 1st of every
month. So if the session spans midnight it may change the CUI.
> 2) if the home server does check and notice that it has
> changed, then it should
> send an Access-Reject.
This is just in case the NAS changed the value of CUI. It should never do
this. But to be complete that clause says what will happen.
> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Tuesday, April 26, 2005 2:54 AM
> To: farid.adrangi@intel.com; aboba@internaut.com
> Cc: radiusext@ops.ietf.org; dnelson@enterasys.com
> Subject: RE: Issue 83: CUI and re-authentication
>
>
> Farid,
>
> I edited your text somewhat:
>
> When reauthenticating, 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 verify that the value of CUI matches the
> the CUI from the previous Access-Accept If the verification
> 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.
>
> But I am confused by this; you are stating that
>
> 1) the CUI may change during reauthentication, but the home
> server doesn't need
> to check if it has changed.
> 2) if the home server does check and notice that it has
> changed, then it should
> send an Access-Reject.
>
> What is the purpose of this, if checking is optional? A MAY
> followed by a SHOULD is not really create deterministic
> behavior. Can you explain in a bit more detail what kind of
> behavior you are trying to get?
>
> John
>
>
> > -----Original Message-----
> > From: owner-radiusext@ops.ietf.org
> > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Adrangi, Farid
> > Sent: 26 April, 2005 07:12
> > To: Bernard Aboba
> > Cc: radiusext@ops.ietf.org; Nelson, David
> > Subject: RE: Issue 83: CUI and re-authentication
> >
> >
> > 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/>
> >
>
> --
> 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/>