Folks,
I have been sorting through the email trail on this one. In my
opinion, there is *rough* consensus for the notes and approach that I
proposed in this email. Minor revisions were suggested, but the
subsequent email thread seems to show the stated text was acceptable.
I have also reviewed the "key derivation differences" thread. To
quote Jouni's email from
24 February:
In other words, we cannot come up with a EAP-MSCHAPv2 MSK derivation
rules that would cleanly fit into all deployed uses and there will
unfortunately be need for tunnel method specific exception in either
EAP-PEAP with cryptobinding or EAP-FAST. Either way, it would be
useful to get this documented clearly so that all future uses of EAP-
MSCHAPv2 would be able to refer to an existing specification instead
of having to come up with their own MSK/ISK derivation rules as was
done with EAP-PEAP cryptobinding and EAP-FAST.
I agree that it will be good to get this documented clearly for future
specs, but do not see an impact on current specs, so I am not
requesting any further changes to the documents.
Accordingly, I have asked the IESG Secretary to forward the proposed
IESG notes to the RFC
Editor.
Thanks,
Tim Polk
On Feb 11, 2009, at 9:26 AM, Tim Polk wrote:
Folks,
As the AD that sponsored publication of the EAP-FAST documents under
discussion,
I have been trying to find the best way forward. I believe that the
best course of action
involves some clarifications to draft-cam-winget-eap-fast-
provisioning to distinguish
the modified and unmodified use of EAP-MSCHAPv2, and IESG notes to
ensure these
publications do not establish precedent for future reuse of EAP type
codes with
different semantics.
First, I support revising draft-cam-winget-eap-fast-provisioning so
that the modified
form of EAP-MSCHAPv2 is consistently referred to as EAP-FAST-
MSCHAPv2. The
authors offered to make this change earlier in the thread, and I
have seen some
support and no opposition to this suggestion.
Second, I will be offering the following text for IESG notes on both
documents. The
notes clearly state the drawbacks for EAP type code reuse and define
an acceptable
path for future protocol developers.
------ draft-cam-winget-eap-fast-provisioning -----
EAP-FAST has been implemented by many vendors and it is used in the
Internet. Publication of this specification is intended to promote
interoperability by documenting current use of existing EAP methods
within EAP-FAST.
The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code
assigned to
EAP-MSCHAPv2 (26) for authentication within an anonymous TLS
tunnel. In
order to minimize the risk associated with an anonymous tunnel,
changes
to the method were made that are not interoperable with EAP-
MSCHAPv2.
Since EAP-MSCHAPv2 does not support method-specific version
negotiation,
the use of EAP-FAST-MSCHAPv2 is implied by the use of an anonymous
EAP-FAST tunnel. This behavior may cause problems in
implementations
where the use of unaltered EAP-MSCHAPv2 is needed inside an
anonymous
EAP-FAST tunnel. Since such support requires special case
execution of
a method within a tunnel, it also complicates implementations
that use
the same method code both within and outside of the tunnel
method. If
EAP-FAST were to be designed today, these difficulties could be
avoided
by utilization of unique EAP Type codes. Given these issues,
assigned
method types must not be re-used with different meaning inside
tunneled
methods in the future.
---- draft-zhou-emu-fast-gtc ------
EAP-FAST has been implemented by many vendors and it is used in the
Internet. Publication of this specification is intended to promote
interoperability by documenting current use of existing EAP methods
within EAP-FAST.
The EAP method EAP-FAST-GTC reuses the EAP type code assigned to
EAP-GTC (6). The reuse of previously assigned EAP Type Codes is
incompatible with EAP method negotiation as defined in RFC 3748.
Since
EAP-GTC does not support method-specific version negotiation,
the use of
EAP-FAST-GTC is implied when used inside the EAP-FAST tunnel during
authentication. This behavior may cause problems in
implementations where
the use of another vendor's EAP-GTC is required. Since such
support requires
special case execution of a method within a tunnel, it also
complicates
implementations that use the same method code both within and
outside of
the tunnel method. If EAP-FAST were to be designed today, these
difficulties could be avoided by utilization of unique EAP Type
codes.
Given these issues, assigned method types must not be re-used with
different meaning inside tunneled methods in the future.
I am not under the illusion that this text will be entirely
satisfactory to anyone,
but I believe that it is an *appropriate* resolution to the problem.
Thanks,
Tim Polk
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
