|
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@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf