[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 83: CUI and re-authentication
Avi Lior <> supposedly scribbled:
> 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.
Maybe this stuff could actually be explained in the draft?
>
>
>> -----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/>
Hope this helps,
~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/>