[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/>