Hello,
I was pleasantly surprised to find this draft in Last Call. I have
reviewed it and my comments follow.
Issues with prf and prf+
- In sections 5.1 and 5.2 the password is passed directly into prf+
(which is the same as the one from RFC 2409 and uses HMAC-SHA1 or
HMAC-SHA256). This is a key derivation type function and assumes it
has been passed a key having properties, like a uniformly random
distribution, that a low-entropy password does not have.
I recommend deriving a key for Encr() in a 2-step process using and
"extractor and expander" KDF. It might also be good to mention that
the first, leftmost, length-of-cipher-key bits are used as the cipher
key.
- In sections 5.2 and 5.3 prf+ is used to generate keys whose lengths
are not indicated. Ke is the encryption key and it's pretty easy to
infer that length, but Ki and Ka are used with a keyed MAC function,
again either HMAC-SHA1 or HMAC-SHA256, and what are the lengths then?
RFC 2104 (the one defining HMAC) says, "The authentication key K can
be of any length up to B, the block length of the hash function." B
for both of these hash functions would be 512 bits. Longer keys are
hashed down to the digest size of the hash function which is 160 bits,
for HMAC-SHA1, and 256 bits, for HMAC-SHA256. So what's the length of
Ka and Ki? 512 bits for both? 160 bits for HMAC-SHA1 and 256 bits
for HMAC-SHA256?
I recommend specifying exactly what length of key is used and if
new keyed MAC functions can be defined in the future to put something
in the IANA recommendations (section 7.4) saying that new functions
must exactly specify their key length.
- On a similar note, section 5.2 says the length of the nonces "MUST be
the maximum of 128 bits, and half the key size of the negotiated PRF".
First of all, why is this based on the PRF? Do you mean the
negotiated MAC? And second of all, the PRF (and the MAC!) takes a
variable length key so what is "the key size of the negotiated PRF"?
If my recommendation above on specifying the length of the keyed MAC
function is accepted then all I'd recommend here is change PRF to MAC
since that's the function being used to integrity protect the nonce.
Issue with password normalization
- Section 5.1 says "If the password is non-ASCII, it SHOULD be normalized
by the sender before the EAP-EKE message is constructed. The
normalization method is SASLprep, [RFC4013]. Note that the password
is not null-terminated."
I don't think this will work. The SHOULD should be a MUST and the
mention of SASLprep should use normative language-- i.e. it "MUST
be SASLprep". Is there a mandatory-to-implement format? Is support
for ASCII a MUST? Also, there's no mention of unassigned code points?
What happens if one of these is hit during normalization? I don't
believe the text as written will assure interoperability and it will
also be a DISCUSS target, said using the voice of experience :-)
Encrypted Nonces
- Why is CBC mode used to encrypt the nonces? They MUST be random so
the IV is not providing anything useful to the encryption. I think
ECB mode should be used, or else some justification for using an IV
should be provided. This comment applies to Encr() only, please see
my comment below on using RFC 5297 for Prot().
Issues with the component exchanges
- The original EKE protocol had an exchange of encrypted nonces that
both proved possession of the shared secret (and therefore proved
knowledge of the password) and proved liveness. This protocol keeps
the encrypted nonce exchange and adds an "auth" exchange whose only
purpose, apparently, is to protect the negotiated options and the
channel binding information.
I recommend getting rid of the Auth exchange and binding the
information being protected by the Auth exchange into the encrypted
nonces. If one looks at encrypting the nonces as key wrapping a fine
tool for this job comes to mind: RFC 5297. This cipher mode can
"wrap" arbitrarily-sized data (no need for padding!) and it accepts
additional associated data (AAD) that is authenticated but not
encrypted. The options and any channel binding information could be
AAD to the wrapping of the nonce(s). Any mischief involving a downgrade
attack or mucking with the channel binding information would be
detected because the nonce could not be unwrapped and the exchange
would fail on that account.
This would simplify the exchange and make it more "faithful" to the
original and, I think, easier to analyze. It would also simplify
the protocol in other ways: no more need to negotiate a MAC function,
no more need to derive Ka, and the Protected Field Structure in Figure
6 can be simplified by removing the ICV and the Random Padding when
used in Prot().
If my comment above on using ECB for Encr() is accepted then this
would further simplify things. Encr() is ECB encryption of a padded
blob, no IV no ICV; and Prot() is a wrapped nonce with AAD and an IV.
- The notation is a bit confusing. There's a "Commit exchange [where]
the peer and server exchange information to generate a shared key
and also to bind each other to a particular password." And there's a
"Confirm exchange [where] the peer and server prove liveness and
knowledge of the password by generating and verifying verification
data." But that's not what happens.
There's a Commit_P which, one assumes, represents the peer's value
it is providing in the Commit exchange but there is no corresponding
Commit_S that one would naively expect in which the server provided
it's commitment. And that's because part of the properties of the
Confirm exchange are in the Commit exchange (specifically the Prot()
data) and the properties of the "Commit exchange" are met without use
of Commit_S/P payloads. The "Commit_P", while being technically in
the "Commit exchange", doesn't really do anything about exchanging
information to generate a key and bind the peer to a password guess
(the point of the "Commit exchange").
I recommend cleaning this up by removing the Commit/Confirm
terminology. Explain what each of the messages in the protocol is
doing since there isn't a clean demarcation for separate Commit and
Confirm exchanges. Of course, if my recommendation above on using
RFC 5297 is accepted then this job becomes much easier too!
Issues with Channel Binding
- I suggest mentioning in section 4.2.2 that the CBValue is outside
of both Prot() and Encr() protection when the payload in Figure 6
is used for Prot() and Encr(). It took a while, and lots of page
flipping back and forth to figure that out.
- What is the significance of the asterisk on the CBValue in Figure 4?
- CBValue "MAY be repeated multiple times, once per each value
transmitted" is a bit hard to parse. Do you mean there MAY be
multiple occurrences of CBValue in a payload but each Channel Binding
Type MUST only occur once in each payload? If so, why? How do you
know what CBValues will be defined in the future? Maybe there will
be some CBValue Type whose semantics are fine when that type occurs
multiple times in a single payload.
I suggest to say "MAY be repeated multiple times in a single
payload." and just leave it at that.
- What is the point of Channel Binding? If there is a problem being
solved then define some types in section 7.6 and show that problem
being solved in section 4.5. If there is no problem to solve then
there is no need to include this in the protocol and certainly no
need to make IANA maintain a registry of these things with no use.
Issues with elliptic curves cryptography
- Section 5.1 and 8.2 mention using ECC. ECC cannot be used with
this particular instantiation of EKE.
I recommend removing the note in section 5.1. I also recommend
removing the reference to some future draft that might instantiate
a different version of EKE in which ECC can be used. If such a
thing is ever published it will be a stand-alone document. Furthermore,
I recommend section 7.1 state that ECC domain parameter sets MUST
NOT be added to the "Diffie-Hellman Group Registry" maintained by
IANA for this protocol. If a future document is generated that somehow
uses ECC with an EKE variant it can refer to this registry for MODP
groups and define a new registry, or refer to a different existing
registry, for ECC groups.
Miscellaneous Nits and Picks
- I suggest adding the IDs into the SharedSecret derivation in section
5.2. This will bind them to all keys derived from SharedSecret, like
the EMSK/MSK. It's probably a good idea to have keys bound to the
(authenticated) identities that created them. If you do this you can
remove the IDs from derivation of Ke and Ki:
SharedSecret = prf(0+, g^(x_s*x_p) mod p | ID_S | ID_P)
Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys")
- Both bits and bytes are used (e.g. section 5.5). I suggest picking
one and sticking to it, and I recommend bits.
- Section 7.1 defines a registry of "Diffie-Hellman Groups" for use
with this exchange. It says things like "The prime number of group X
[RFC3526], with the generator of Y". I think it would be good to
add instructions for IANA to fill in the domain parameters from
that RFC and not refer to it, making this new registry complete.
Issues with Copyright
- This draft is 'trust200902' but includes much text, and is obviously
derived from, a draft that is 'pre5378Trust200902'. I don't know
if that's an issue or not but it might be wise to check.
For instance, the first 3 paragraphs are lifted directly (with the
only change being s/pwd/EKE/) from draft-harkins-emu-eap-pwd. So
is figure 1, a complete paragraph in section 3.1 and huge portions
of the Security Considerations (and other stuff). The draft does say
"Much of this document is unashamedly picked from" the other draft
as well as draft-pppext-eap-srp. I'm not complaining (I'm actually
flattered) but I do think that the copyright might need to changed.
Or at least get a sign-off from a competent individual to say a
change is not needed.
regards,
Dan.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf