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

[Soliman, Hesham (H.Soliman]

Hi Thomas, 

Thanks for your comments. Some responses inline.


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

=> ok, that's something to consider for future updates.

 > >  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. 

=> It should ;). It's another method that relies on pre-shared keying.

 > 
 > >   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. 

=> We're aware of other proposals on this topic, more below.

 > 
 > >     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 :-/

=> Which one ? all of the above? 

 > To conclude, the proposal does not seem to introduce new features,
 > which could not be solved with existing EAP methods. 

=> By "existing", do you mean documented in RFCs? I would disagree
with that. If you mean "existing" in other drafts, then yes there
is a lot in common. But there are other features that are not in 
all other proposals, e.g. TmpNAI allocation for anonymity. 

 > Probably, it would
 > have been better to look first what proposals have already 
 > been published.

=> Let me first assure you that we are fully aware of other 
proposals. As mentioned in the introduction of the draft, this 
method was designed a few years ago, implemented and deployed
commercially. For several reasons, it wasn't published at the 
time. Now, I'm aware that there are alternatives in this WG
and we're not trying to replace existing concensus, but we'd like
to add this method for consideration for PS. Since it is already
deployed we'd like to publish it as an alternative. 
At the same time, if there are technical problems with the draft
we'd love to know about them. 

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

=> Of course we were aware of them before writing the draft. But 
we were not aware of any mechanism back in 2002/3 when this 
was implemented/deployed.

Hesham


===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================