Re: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id for EAP GPSK
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id for EAP GPSK
Sounds reasonable, but I'm not entirely sure I'd call the ID_Server
unauthenticated. It's authenticated in GPSK-3 when the server includes
it in the key derivation to compute SK. If the value was changed by an
attacker, the authentication would fail.
--
t. charles clancy, ph.d. | tcc at umd.edu | www.cs.umd.edu/~clancy
Bernard Aboba wrote:
EAP GPSK defines the Method-Id as follows:
" o MID = KDF_Zero-String ("Method ID" || EAP_Method_Type ||
CSuite_Sel || inputString)[0..15]"
The inclusion of the EAP_Method_Type doesn't seem quite right, because
the Method-Id only needs to be globally and temporally unique for a
given EAP method; since Session-Id = Type Code || Method-Id, the
Session-Id's are guaranteed not to colide between EAP methods.
Note that in this case inputString = 'RAND_Client || ID_Client ||
RAND_Server || ID_Server' so that the identities are included. I think
that this is a good idea since it should guarantee a unique Method-Id
even if the same client and server RAND values are chosen by a different
(peer, server) set.
In reading the document, it would appear that Peer-Id (ID_Client) is
authenticated in this protocol, whereas the Server-Id is not (e.g.
ID_Server is asserted, but not really authenticated). Therefore, I
would suggest addition of some text discussing this. For example:
The EAP-GPSK Session-Id is the concatenation of the EAP Type Code (TBD)
with the contents of the Method-Id defined in Section X.
The Peer-Id is the contents of the ID_Client field. Note that the
contents are used as they
are transmitted. The Server-Id is an empty string.
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.