Subject: [eap] RE: Comments to <draft-vanderveen-eap-make-00.txt>

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 1 Sep 2005 09:53:45 -0400

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

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked]
Date: Thu, 01 Sep 2005 17:22:39 +0200

Hi Hesham, 

thanks for your immediate response! 

> > authentication protocol.

In detail: 

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

     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.

     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

<snip>    
To generate the desired OutputLength octet length of key material, 
the T-PRF is iterated as follows:  
     
  T-PRF (Key, S, OutputLength) = T1 + T2 + T3 + T4 + ... 
          Where S = label + 0x00 + seed;  and 
     
    T1 = HMAC-SHA1 (Key, S + OutputLength + 0x01) 
    T2 = HMAC-SHA1 (Key, T1 + S + OutputLength + 0x02) 
    T3 = HMAC-SHA1 (Key, T2 + S + OutputLength + 0x03) 
    T4 = HMAC-SHA1 (Key, T3 + S + OutputLength + 0x04) 
</snip>

How much lines of code would this require? One? Two? 

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.

But this is a rule of thumb in theory, isnt it? 

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. 

     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?

See previous comment. 

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

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 

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

Regards  

Thomas

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 1 Sep 2005 13:30:48 -0400

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.

 > the Bellare-Rogaway attack model). 

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

 > receiver). However, there are a lot of proposals which have 

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

 > Take EAP-FAST as an example. As PRF, the following 

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

 > does not provide this feature, it belongs to the advantages 

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

 > which is not needed at all.  Am I right?

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

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

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

 > 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