Subject: [Emu] Issue: Definition of Session-Id, Peer-Id, Server-Id for EAP GPSK

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 19 Nov 2006 22:19:57 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Charles Clancy <[email-masked]>
Date: Mon, 20 Nov 2006 21:01:52 -0500

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.  |  [email-masked]  |  www.cs.umd.edu/~clancy

Bernard Aboba wrote:
> "   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.
> 
> 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.
> 
> 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:
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 22 Nov 2006 08:51:47 -0800

>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 

The client only confirms that the server has access to the PSK, but it 
doesn't confirm the specific server identity.  This is different from 
TLS-based EAP methods where the client can verify a certificate issued to a 
specific server.