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
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.
3.1. AT_KDF_INPUT
Network Name Example:
=====================
The value for the Access network identity forin HRPD access
networks is specified in 3GPP2X.S0057-0[15] and the format
for the HRPD Access Network Identity is specified in table below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type of Access | Length |Value |
| Network | (Octets) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|3GPP2 HRPD | 4 |Fixed string "HRPD", converted|
| | |into an octet string according|
| | |to section 6.4.2.4.3 of |
| | |3GPP [TS.24.302] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.2. AT_KDF
Peer
Authenticator
| EAP-Request/AKA'-Challenge |
| (AT_RAND, AT_AUTN, AT_KDF[1],AT_KDF[2], AT_KDF_INPUT, AT_MAC) |
|<-------------------------------------------------------------------------|
| |
| |
| |
| EAP-Response/AKA'-Challenge |
| Peer sent selected alternate (AT_KDF[2]) |
| to server |
|------------------------------------------------------------------------->|
| |
| EAP-Request/AKA'-Challenge |
| (AT_RAND,AT_AUTN,AT_KDF[2],AT_KDF[1],AT_KDF[2],AT_KDF_INPUT,AT_MAC)|
|<-------------------------------------------------------------------------|
| |
| |
| EAP-Response/AKA'-Challenge |
| (AT_RES, AT_MAC) |
|------------------------------------------------------------------------->|
Figure-2: EAP-AKA' Authentication Process with multiple AT_KDFs and
alternate selection of the AT_KDF by peer.
In the section [4. Bidding Down Prevention for EAP-AKA] we can add the
Figure -3 and Figure-4.
4. Bidding Down Prevention for EAP-AKA
Behaviour of the Peer with AT_BIDDING is shown below:
Peer Authenticator
| EAP-Request/AKA-Challenge |
| (AT_RAND, AT_AUTN, AT_BIDDING, AT_MAC) |
|<------------------------------------------------------|
| |
| EAP-Response/AKA-Challenge |
| Peer do not support EAP-AKA' |
| (AT_RES, AT_MAC) |
|------------------------------------------------------>|
Figure-3: Peer do not support EAP-AKA'
Peer Authenticator
| EAP-Request/AKA-Challenge |
| (AT_RAND, AT_AUTN, AT_BIDDING, AT_MAC) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/AKA-Authentication-Reject |
| Peer support EAP-AKA' |
|------------------------------------------------------>|
Figure-4: Peer support EAP-AKA'_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
