eap Mailing List: Comments on <draft-vanderveen-eap-make-00.txt>

[t . otto (t.otto]

Hi Hesham, Michaela,
 
below my thoughts while reading your proposal.



> 3. Protocol Description
>  
> 3.1. Overview and Motivation of EAP-MAKE
>
>    The EAP-MAKE authentication protocol is a native EAP authentication
>    method. That is, a stand-alone version of EAP-MAKE outside of EAP is
>    not defined. EAP-MAKE is designed to enable mutual authentication,
>    based on pre-shared keys and well-known public cryptographic
>    algorithms. This method is ideal for subscription-based public access
>    networks, e.g. cellular networks.
>
>    Regarding the name of this method, its abbreviation is the same as a
>    method that was published in an Internet-Draft in 2001. The draft has
>    not been renewed since then. The name EAP-MAKE was chosen in 2002 for
>    a method implemented for commercial deployment at Flarion
>    Technologies, without awareness of the aforementioned draft.

EAP-MAKE has an assigned IANA EAP type number, 27. I think in this context,
the name "EAP-MAKE" is not more available.


>    EAP-MAKE assumes a long-term or pre-shared secret known only to the
>    Peer and the Server. This pre-shared secret is called the Root
>    Secret. The Root Secret consists of a 16-byte part Root-Secret-A, and
>    16-byte part Root-Secret-B

This sounds somehow familar ... continuing reading ...

>  The Root-Secret-A secret is reserved for
>  use local to the EAP-MAKE method, i.e. to mutually authenticate the
>  EAP Peer and EAP Server. The Root-Secret-B secret is used to derive
>   other quantities such the Master Session Key (MSK) and Extended
>   Master Session Key (EMSK). Root-Secret-B and Root-Secret-A MUST be
>   cryptographically separate.

Yes, no doubt anymore.
This remembers me on EAP-PSK.

>   When a Backend Authentication Server is used, the Server typically
>   communicates with the Server using an AAA protocol. The AAA
>   communications are outside the scope of this draft.

>   Some of the advantages of EAP-MAKE consist of:

>     o based on well-established Bellare-Rogaway mutual authentication
>   protocol.

I do not manage to find the reference in the back of the draft.
Do you mean "Entity Authentication and key distribution", by
M. Bellare and P. Rogaway?

There are already two EAP methods, EAP-Archie and EAP-PSK, which
also build on this theoretical work.


>     o supports key derivation for local EAP method use and for export
>   to other third parties to use them independently of EAP.
>     o employs only two request/response exchanges.

Yes, but all four protocols of Bellare-Rogaway (MAP1, MAP2, AKEP1, AKEP2)
consists only of four messages. Where is then exactly the advantage?

>     o relies on the IEEE 802.11i function for key derivation and
>   message integrity. This way a device implementing a lower-layer
>   secure association protocol compliant with IEEE 802.11i standard will
>   not need additional cryptographic code.
>     o encryption algorithm is securely negotiated (with no extra
>   messages) but encryption use is optional.
     o keys used for authentication and those used for encryption are
   cryptographically separate.
     o user identity anonymity can be optionally supported.
     o no synchronization (e.g. of counters) needed between server and
   peer.
     o no one-time key pre-processing step.

Sorry, this does not convince the reader :-/



To conclude, the proposal does not seem to introduce new features,
which could not be solved with existing EAP methods. Probably, it would
have been better to look first what proposals have already been published.

I am interested whether you was aware of the abovementioned proposals
before writing this proposal.

/Thomas