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

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