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
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
