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
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf