Thanks. It will be great if you can handle it in AUTH48.
Moreover, I found a mistake in the RFC-4187 which creates a confusion
about the P (Phase-bit).
This needs to be corrected.
See below the problem description:
Statement-1: If the P bit is set to zero, the notification can only be
used after a successful EAP/AKA-
Challenge round in full authentication or a
successful EAP/AKA-Reauthentication round in
re-authentication.
Statement-2: If the P bit is set to one, the notification can only by
used before the EAP/AKA-Challenge
round in full authentication or before the
EAP/AKA-Reauthentication round in reauthentication.
Statement-1 and Statement-2 taken from the section [6.1. General],
we have details of the
P bit as given below:
The second most significant bit of the notification code is called
the Phase bit (P bit). It specifies at which phase of the EAP-AKA
exchange the notification can be used. If the P bit is set to zero,
the notification can only be used after a successful EAP/AKA-
Challenge round in full authentication or a successful EAP/AKA-
Reauthentication round in re-authentication. A re-authentication
round is considered successful only if the peer has successfully
verified AT_MAC and AT_COUNTER attributes, and does not include the
AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-Reauthentication.
If the P bit is set to one, the notification can only by used before
the EAP/AKA-Challenge round in full authentication or before the
EAP/AKA-Reauthentication round in reauthentication. These
notifications can only be used to indicate various failure cases. In
other words, if the P bit is set to one, then the S bit MUST be set
to zero.
Statement-3: If the P bit is set to zero, then the notification code
can only be used before
authentication has occurred.
Statement-4: If the P bit is set to one, then the notification code
can only be used after authentication.
Statement-3 and Statement-4 taken from the section
[11. IANA and Protocol Numbering Considerations], we have details of
the P bit as given below:
The AT_NOTIFICATION attribute contains a 16-bit notification code
value. The most significant bit of the notification code is called
the S bit (success) and the second most significant bit is called the
P bit (phase). If the S bit is set to zero, then the notification
code indicates failure; notification codes with the S bit set to one
do not indicate failure. If the P bit is set to zero, then the
notification code can only be used before authentication has
occurred. If the P bit is set to one, then the notification code can
only be used after authentication.
Statement-1 and Statement-3 is contradicting each other. Similarly,
Statement-2 and Statement-4 is contradicting each other.
Correction is needed in the Statement-3 and Statement-4 with
replacing with Statement-5 and Statement-6
Statement-5: If the P bit is set to zero, then the notification code
can only be used after
authentication has occurred.
Statement-6: If the P bit is set to one, then the notification code
can only be used before
authentication.
Thanks and Regards
Yogendra Pal
On Thu, Dec 4, 2008 at 1:02 PM, Jari Arkko <[EMAIL PROTECTED]> wrote:
> Thanks for the input. The draft has already been approved, but I can look at
> this during AUTH48.
>
> Jari
>
> yogendra pal wrote:
>>
>> Hi Jari,
>>
>> I would like to contribute some figures which could be useful in
>> representing peer's behaviour in scenario mentioned in the
>> draft-arkko-eap-aka-kdf-XX.
>>
>> 1. We can add in the section [3.1. AT_KDF_INPUT] a real example of the
>> network name of the access network for which the
>> authentication is being performed.
>> 2. In the section [3.2. AT_KDF], we can add this Figure-2 for showing
>> the alternate AT_KDF is selected by peer and sent back
>> to the server and, in response to this message, server re-sends
>> AKA'-Challenge by updating the AT_KDF list with preferred
>> AT_KDF in the first position.
>> 3. In the section [4. Bidding Down Prevention for EAP-AKA] we can add
>> the Figure -3 and Figure-4.
>>
>> For points [1, 2, 3], see the attached text file for the example and
>> figures (figure-2,3,4).
>>
>> Thanks and Regards
>> Yogendra Pal
>>
>
>
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
