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

[Soliman, Hesham (H.Soliman]

Thomas, 

Thanks again. I'll answer some of the coments below, but 
let me first make a couple of points clear:

We can debate what the advantages are below, which is 
a useful debate and we'll continue to do that. However, 
let me iterate the main differences (I don't know if you'll
consider them advantages or not) with other proposals:
 - TmpNAI allocation
 - Ciphersuite negotiation
 - Deployment status.

Having said that, this is not an attempt to replace other
mechanisms. If the WG wants more than one mechanism it's fine 
with us. But we should get into the technical side of 
things a bit more.



 > 
 > In detail: 
 > 
 > 
 >    Some of the advantages of EAP-MAKE consist of:
 > 
 >      o based on well-established Bellare-Rogaway mutual 
 > authentication
 >    protocol.
 > 
 > You can not say it is an advantage to make use of a well-analyzed
 > cryptographic algorithm which enjoys a security proof (at least in 
 > the Bellare-Rogaway attack model). 

=> Why not? It's a good thing to use a well-understood mechanism.

 >      o supports key derivation for local EAP method use and 
 > for export
 >    to other third parties to use them independently of EAP.
 > 
 > Where is the advantage? Since you offer encryption (at least 
 > optional)
 > it makes sense to generate keying material for usage within 
 > the EAP method,
 > and then keying material to meet the requirements of RFC 4017. 
 > 
 > 
 >      o employs only two request/response exchanges.
 > 
 > Not only important is the number of roundtrips, but also the 
 > computational
 > costs of their construction (for the sender) and their 
 > verification (for the 
 > receiver). However, there are a lot of proposals which have 
 > only two rountrips.
 > 

=> In the two comments above you seem to interpret "advantage"
as "better than everyone else". That's not the meaning of the 
word. We could just as easily replace it with "useful attributes".

 > 
 >      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.
 > 
 > 
 > Take EAP-FAST as an example. As PRF, the following 
 > construction serves

=> So what? We didn't say we're better that EAP-FAST.


 >      o encryption algorithm is securely negotiated (with no extra
 >    messages) but encryption use is optional.
 > 
 > 
 > Yes .. because this is a *mandatory* requirement of RFC 4017, 
 > that ciphersuite negotiation must be adequately protected.
 > Again, no advantage, but an attempt to meet the requirements.
 > 
 > 
 > 
 >      o keys used for authentication and those used for encryption are
 >    cryptographically separate.
 > 
 > But this is a rule of thumb in theory, isnt it? 
 > 
 > 
 >      o user identity anonymity can be optionally supported.
 > 
 > This is a recommended requirement of RFC 4017. Since other methods
 > does not provide this feature, it belongs to the advantages 
 > of "EAP-MAKE"
 > over other EAP methods. 

=> Again, you misinterpret what we meant. We didn't say "Advantages
over EAP-Archie, PSK and FAST". We've listed what we thought were
useful features. 

 >      o no synchronization (e.g. of counters) needed between 
 > server and
 >    peer.
 > 
 > No advantage. You can not say it is an advantage not to use a thing
 > which is not needed at all.  Am I right?

=> No. Some algorithms require synch between the peer and server.

 > 
 > The point is, that I have followed the development process 
 > of another EAP method,
 > which was initiated in January 2004 and is currently in 
 > version 09 and still in review. That is, a almost two years 
 > enduring process has yielded in some result which is worth 
 > to be called "mature". 

=> Great, we're not trying to affect that. 

 > 
 > Now, over night, a new EAP method is published which 
 > * apparently (although further analysis is needed) does not 
 > have all the teeting 
 >   problems new proposals usually have, but seems moreover to 
 > be very mature. 
 > * and does not introduce (except perhaps the optional 
 > identity protection) new
 >   features, but is very very close to existing proposals 

=> I understand that this would come as a surprise to people
not working with us, but at the same time I'm sure you can
understand that people publish when the time is appropriate 
for them. So let's take the discussion past the historical
precedence since we're not trying to kill existing proposals.

 > 
 > This may not be understood as reproach, but however, this might
 > explain you as an author my missing enthusiasm for "EAP-MAKE".

=> Understood, but I'd like to go past the "surprise" factor
and get into the technical/process issues that the WG wants 
to take. I'm sure it's a win-win situation for all people
involved if an existing solution gets owned by IETF and follows
the security requirements of this organisation, as opposed to
letting it go wild in the proprietary domain. 

Hesham

 > 
 > 
 > Regards  
 > 
 > Thomas
 > 

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