review of draft-sheffer-emu-eap-eke-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]