Subject: [Emu] Early chair review of EAP-AKA' PFS

From: Mohit Sethi <[email-masked]>
Date: Fri, 3 Aug 2018 12:15:27 +0300

Hi Jari and co-authors,

Here is a review of the EAP-AKA' PFS draft version 02. Note, none of 
these comments preclude its working group adoption and these can be 
addressed before or after adoption as a working group item.

- Use of DH vs. DHE vs. ECDH vs. ECDHE

The draft almost uniformly refers to Diffie-Hellman (DH) key exchange. 
However, we can't achieve perfect forward secrecy (PFS) if static 
Diffie-Hellman keys are used. Therefore it might make sense to refer to 
Ephemeral Diffie-Hellman (DHE) and Ephemeral Elliptic Curve 
Diffie-Hellman (ECDHE) instead of DH. The use of DH throughout the draft 
is also surprising when only one elliptic curve is currently specified 
for the key exchange in the draft. If only elliptic curves will be 
supported (currently and in the future), then you can use ECDHE 
throughout. Otherwise, you can use the notation (EC)DHE.

- Use of g^x and g^y in message exchanges

The traditional notation of public keys g^x and g^y and derivation of 
the secret g^xy is useful and easy for understanding. The strength of 
the secret here is based on the discrete logarithm problem. For Elliptic 
Curve Diffie-Hellman, the notation would be a different (both parties 
have public keys as points on the agreed curve and after the key 
exchange, both parties compute another point on curve which is the 
shared secret). The strength of the secret here would be based on the 
elliptic curve discrete logarithm problem. The use of g^x and g^y while 
only supporting a single elliptic curve might confuse readers. It might 
be useful to at least add that g^x and g^y are used for notation and 
corresponding public keys of ephemeral elliptic curve diffie-hellman can 
be used in the messages (if both DHE and ECDHE are to be supported). If 
only ECDHE is supported, then it might make sense to explicitly clarify 
that g^x and g^y are used are for notation only. As another option, you 
can simply refer to them as PKs and PKp for public keys of server and peer.

- Negotiation of the ECDHE curve

I think this needs some more clarification. The AT_KDF_DH is used for 
deciding which ECDHE curve is used for the public key in AT_PUB_DH. So 
as the draft currently says, it is possible for the the server to send 
several AT_KDF_DH attributes in the order of preference. Does this also 
mean that it sends several AT_PUB_DH in the same order? I am afraid the 
message size may explode and without any fragmentation support, this is 
bound to fail. I guess you might initially send only one AT_PUB_DH with 
the most preferred AT_KDF_DH. If the client/peer does not support that 
and chooses a different AT_KDF_DH from the list, then a new EAP-Request 
is sent with a different AT_PUB_DH. Also, currently the peer will need 
to do AT_KDF and AT_KDF_DH negotiation separately, because 
EAP-Response/AKA'-Challenge message can contain only one attribute 
AT_KDF or AT_KDF_DH depending on what are you negotiating. Shouldn't 
they be done at the same time?

- Encoding the (EC)DHE public keys sent to Peer and Server

Currently the draft says at that the AT_PUB_DH contains the public value 
of the Diffie-Hellman key, and for curve25519 it is 32 bytes long.  As 
the test vectors in RFC 7748 say, that is 32 binary bytes. You would 
need to encode the public key when sending on the wire which would 
increase the size. Section 5.2 of RFC7748 shows the public key with 
Curve25519 key as hex encoded. I would strongly recommend encoding the 
public keys when sending on the wire with something like JSON Web Key 
(JWK). Also, Curve25519 is special. Most other curves have a public key 
as a point x and y. Without proper encoding it would be hard to 
interpret which bytes are x and which bytes are y and therefore 
inter-operable implementations would be challenging.

- No KDF on Z derived from EC(DHE)

The shared secret resulting from a EC(DHE) exchange is typically denoted 
as Z (perhaps you can use that instead of g^xy). This comment is related 
to the use of g^xy in the derivation of MSK, EMSK and other parameters 
shown in Section 6.3. I am not an expert with PRF vs KDF and others with 
more expertise maybe able to help more. My understanding is that a PRF 
places more stringent requirements on the uniform distribution of the 
secret key that is used. It might be better to pass Z though a KDF like 
those in the NIST  800-56A Revision 2 before using it in a PRF.

- The abstract and introduction refers to the RFC5448. Perhaps it should 
be updated to reference the draft-ietf-emu-rfc5448bis-01?

- In Section 1: " we as protocol designs can ask " should be " we as 
protocol designers can ask "

- In Section 1: " within that context will be EAP-AKA. " should be " 
within that context will be EAP-AKA'. "

- In Section 2: " This specification is an initial proposal for ensuring 
SIM-based authentication in EAP makes attacks difficult. Comments and 
suggestions are much appreciated, including design improvements. " 
perhaps can be removed now?

--Mohit