Hi,
Per the potential notes and given feedback thus far, we (the authors)
can address the relevant concerns with updates to the draft(s) as
follows:
1. Update the EAP-FAST provisioning draft to change EAP-MSCHAPv2 to
EAP-FAST-MSCHAPv2 throughout the document where the reference is to its
working inside the EAP-FAST tunnel during anonymous provisioning mode.
Also clarify the use of EAP-FAST-MSCHAPv2 during anonymous provisioning
in section 3.2.3
2. The following text could be added either in the introduction or IANA
considerations (or anywhere the IESG prefers):
"EAP-FAST has been implemented by many vendors and it is used in the
Internet. Publication of this is intended to promote interoperability.
The reuse of EAP-MSCHAPv2/EAP-GTC EAP method IDs with different meaning
and behavior inside the tunnel method might cause problems in some
environments. If EAP-FAST were to be designed today, these difficulties
could be avoided by the assignment of new EAP Type codes, which was more
difficult before RFC 3748 defined expanded EAP Types. The reuse may
cause problems in implementations where the use of unaltered methods is
required. It also can make implementations that use methods both within
and outside of the tunnel method more difficult, since this support
requires special case execution of these methods within a tunnel. Given
these issues, assigned method types must not be re-used with different
meaning inside tunneled methods in the future."
Thanks,
Nancy.
-----Original Message-----
From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
Jari Arkko
Sent: Thursday, February 05, 2009 1:01 AM
To: Bernard Aboba
Cc: emu@ietf.org
Subject: Re: [Emu] Potential Notes in EAP-FAST Documents
Bernard,
> c. EAP negotiation issues. Neither the IESG note nor the text
> explicitly states what is wrong with using an EAP Type Code for
> incompatible versions of an EAP method that does not support version
> negotiation.
They should state this.
> Indeed, it would appear that some
> members of the IESG think that method overloading is required by EAP
> tunneling methods desiring to incorporate support for cryptographic
> binding.
Not sure who you are referring to, but for the record I at least do not
believe that. Cryptographic binding can clearly be achieved without
overloading or re-definition of behaviour of existing components.
> Saying that this "might be difficult
> in some software environments" isn't a good characterization.
> Would the IESG use the same words to describe the reuse of IP protocol
> numbers within an IP tunnel? I doubt it.
I guess this referred to the difficulty of implementing the remedy where
EAP within a tunnel is different from EAP outside the tunnel. In some
cases this would be possible, in some other cases not... depending on
what the software architecture, APIs, etc are. But in all cases it is
painful, which is why this is a bad approach and should not be done by
future methods.
Jari
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
