ietf
[Top] [All Lists]

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

2008-02-03 14:54:34
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
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>