Re: Last Call: draft-ietf-hokey-erx to Proposed Standard

[Lakshminath Dondeti <[e-mail]>]

Hi Anthony,

I am sorry that the quality of the document is not up to your 
expectations.  We tried and the result was satisfactory to many people, 
some of whom chose to explicitly say so.  But, if you have the time, 
please point out our errors and we'll work to fix them in the revision. 
  Your item 7 below alludes to some of the problems and we'll use those 
comments as additional guidance in the revision.

On other issues, please do let me know if you have suggestions to 
improve the current document.  As to taking a different direction, I 
will note that other options, including the one you pointed to, were 
considered and here we are after long and tedious work of the working 
group consensus process.  One of our WG co-chairs wrote one of the 
documents you point to and as of my last conversation with him was 
supportive of the ERP.  Well, I must add that some of the ideas in that 
draft came from him.

In our analysis, we could not come up with a protocol that is as 
efficient as ERX without changes to authentication functionality.  If 
you have such a solution, please write a draft and point us to that.

You use the words "forklift upgrade."  A few days ago I re-flashed 
thirdparty firmware on my almost-bricked WLAN AP in about a few minutes. 
  No forklifts were involved!  Normally, I can upgrade the firmware in 
seconds.

We also have an implementation of the protocol where we changed the 
peers, authenticators and servers, again neither forklifts nor 
screwdrivers were required!

On your point 3, an MSK based hierarchy was considered and after a lot 
of debate and discussion we have the WG consensus that EMSK based key 
hierarchy is the direction.

Your idea of abuse is also quite interesting.  You note that "a popular 
use of EMSK-based key hierarchies is for
implementation of "walled garden" style application authentication based 
on EAP."  If you are suggesting that we at the IETF should not attempt 
open standardization because we will disturb undocumented proprietary 
uses, wait ... is this the IETF?  Perhaps I am in the wrong place.

Finally, we in the HOKEY WG are aware of method-based reauthentication 
mechanisms and were chartered to do better.  Fast handovers in radio 
access technologies using licensed spectrum have very stringent 
requirements.  I tried to get EAP adopted in 3GPP EPS.  They didn't want 
to do it -- too slow and too many messages were the reason.  Many of us 
worked to get it adopted in 3GPP2 UMB.  We succeeded.  We are trying to 
specify method independent reauthentication for faster handovers. 
That's our charter.

Thank you again for your review.  If you want to work together on open 
standardization, I am happy to work with you.  If you think we shouldn't 
publish new proposed standards because you are aware of proprietary 
undocumented extensions of IETF protocols, well then, we have different 
views of what the IETF should be doing.

best wishes,
Lakshminath

On 2/1/2008 1:54 PM, Anthony Leibovitz wrote:
> I've read through [draft-ietf-hokey-erx-08] and oppose adoption this 
> document as a Proposed Standard.
> 
>  
> 
> The key problem with the document is cost associated with deployment and 
> implementation.  In addition to requiring updates to EAP peers and 
> servers, the ERX proposal also requires that authenticators be updated 
> or replaced, because instead of using existing EAP packet types, the ERX 
> proposal requires the addition of new EAP packet types as well as 
> peer-initiated messages.
> 
>  
> 
> As a result ERX requires a forklift ugprade of peers, servers, 
> authenticators and proxies. This is unrealistic, particularly when there 
> are alternatives that can deliver the same performance and the same (or 
> better) security with lower deployment barriers.
> 
>  
> 
> For example, see references [1] and [2], there are existing deployments 
> that only require modifications to EAP peers and authenticators (but not 
> EAP servers), and research papers which describe schemes that only 
> require changes to EAP peers and servers (but not authenticators).
> 
>  
> 
> Given the greater deployment barriers for ERX, some other benefit (such 
> as simplicity, ease of implementation, etc.) needs to be demonstrated to 
> tip the scales in favor of the ERX approach.  Unfortunately, ERX is also 
> more complex than other schemes, and provides no better (and potentially 
> worse) security than the alternatives.
> 
>  
> 
> In addition to these basic issues, the ERX scheme has lots of other issues:
> 
>  
> 
> 1. Proposed key hierarchy - the key hierarchy on which this document is 
> based is complex and unclear.  It adds additional server roles in both 
> single and multi-domain environments, it defines new key types to be 
> generated, maintained and distributed.  Furthermore I am not clear how 
> crypto-agility is supported within the proposed hierarchy. If the 
> assumption is that EAP or EAP methods will do the negotiation then even 
> once platforms are updated to support this technology most existing 
> methods would not work.
> 
>  
> 
> 2. The proposed solution is based on questionable optimizations.  The 
> document requires that RADIUS servers distribute keys to entities 
> without user authentication which would appear to violate RFC 2865.  
> This is done in order to save a round-trip in getting keys to the ERX 
> server.  However, for performance this optimization is not important 
> compared with optimizing the exchange with the local ERX server, since 
> user movement to a new domain presumably only happens infrequently.
> 
>  
> 
> Rather than requiring new EAP messages, it seems that the same goal 
> could have been accomplished using existing
> 
> EAP messages. For example, for the exchange with the local ERX server, 
> previous research at University of Maryland [1]  was based on a single 
> round-trip authenticated exchanges using the EAP-Response/Identity, 
> which requires no authenticator modifications.
> 
>  
> 
> Another performance issue with ERX is that it presumes that adjacent 
> authenticators are all pointed to the same ERX server.  Where 
> deployments balance load by pointing adjacent authenticators to 
> different proxies, the ERX scheme will not perform as well as existing 
> EAP method-specific reauthentication schemes such as EAP-FAST, which 
> allows EAP peers to do fast resume without server-side state.
> 
>  
> 
> 3. Complexity.  From reading the document, I can see little or no 
> security benefit from the EMSK-based key hierarchy, and lots of 
> downside.  Why is it not possible to obtain cryptographically separate 
> keys to be used by authenticators based on the MSK alone?  This approach 
> already deployed, and seems to offer equivalent security without 
> requiring changes to AAA servers (although it does require changes to 
> EAP peers, authenticators and proxies).
> 
>  
> 
> 4. Compatibility with existing EAP lower layers.  The ERX scheme is 
> based on peer-initiated messages, while RFC 3748 assumes that EAP 
> exchanges are initiated by the authenticator. Several EAP lower layers 
> such as IEEE 802.1X-2001 are based on this assumption. RFC 3579 also 
> specifically prohibits "role reversal".  Given that the ability to do a 
> single round-trip "session resume" based on the EAP-Response/Identity, 
> why is it necessary to change the EAP protocol in such a fundamental way?
> 
>  
> 
> The document also appears to change aspects of the EAP state machine 
> defined in RFC 4137, by requiring ERX clients not to respond to 
> EAP-Request/Identity messages.  Why not have the new ERX messages be 
> sent first?  That way, ERX peers will respond immediately, and the 
> EAP-Request/Identity will not need to be sent at all.  Legacy RFC 3748 
> peers will drop the new messages, and will only respond to the 
> EAP-Request/Identity.
> 
>  
> 
> 5. Key state retention and key proliferation - Currently RADIUS servers 
> do not need to retain key state; ERX requires key state retention for 
> multiple independent keys.  This could create a situation where a peer 
> has multiple session keys on a single authenticator increasing the 
> overall system vulnerability.  The result of increasing the volume of 
> keys to be stored on Authenticators is not yet clear but would clearly 
> drive for an increased rate of keys recycled (dropped out of 
> Authenticators) with the obvious result of a much larger rate of session 
> keys generated, weakening of the EMSK and increased ERP-re-auth rate.
> 
>  
> 
> 6. Potential abuses.  While ERX itself is within the RFC 3748 
> applicability statement, many of the potential uses of EMSK-based key 
> hierarchies are not. What is the IANA allocation strategy for EMSK key 
> labels?  Today a popular use of EMSK-based key hierarchies is for 
> implementation of "walled garden" style application authentication based 
> on EAP.  This allows operators to ensure that applications only function 
> if they have available an EMSK-based key.  But is it really sensible to 
> require applications to only run over link layers that support EAP?
> 
>  
> 
> 7. Finally some documentation improvements could improve the consumption 
> of this document. Normally a document will include an Introduction 
> laying out the problem, and perhaps providing some insight into the 
> thinking behind the design.  It might even provide a short overview of 
> related documents.  Instead, the ERX document utilizes a large number of 
> internally defined terms inconsistently without defining them in the 
> glossary.  Acronyms are not spelled out.  This makes the document very 
> difficult to parse, even for readers with familiarity with previous IETF 
> work such as RFC 3748. The document distributes must and may 
> requirements per scenario and does not provide a clear set of 
> requirements per component ensuring that even the most diligent of 
> engineers will miss/misinterpret a required or optional behavior.
> 
>  
> 
> References:
> 
> [1] https://drum.umd.edu/dspace/bitstream/1903/3038/1/interauth.pdf
> 
> [2] http://tools.ietf.org/html/draft-clancy-eap-rekeying-00
> 
>  
> 
> Thanks,
> 
> -Anthony Leibovitz
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/ietf