Subject: Re: [Emu] Potential Notes in EAP-FAST Documents

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Feb 2009 11:25:28 -0800

"
    IESG Note: EAP-FAST has been implemented by many vendors and it is
    used in the Internet.  Publication of this is intended to promote
    interoperability, even though the use of the EAP-MSCHAPv2 and
    EAP-FAST-GTC EAP methods might be difficult in some software
    environments.  If EAP-FAST were to be designed today, these
    difficulties could be avoided by the assignment of new EAP Type
    codes."

Although I concur with the assessments of Glen Zorn, Dan Harkins,
David Mitton and Dorothy Stanley in many respects, I would suggest that
those concerns are outweighed by the IETF's mission to make information
on deployed protocols available to the community.  As a result, I 
believe that the documents should be published, provided that the
following concerns can be addressed:

a. Name confusion.  The use of the term "EAP-FAST-GTC" instead of
EAP-GTC helps clarify that the two protocols are significantly
different.  Similarly, the use of the term "EAP-FAST-MS-CHAPv2"
would help clarify differences between the implementations of
EAP MS-CHAPv2, which I believe go beyond just the use of the
challenge field (e.g. internationalization support). 

b. EAP architecture changes.  Suggesting that EAP methods behave
differently when run within a TLS tunnel negotiating a particular
ciphersuite represents a major change to the EAP architecture
as well as to tunneling methods other than EAP-FAST.  This 
suggestion, if made at all, needs to be restricted solely to
use within EAP-FAST. 

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.  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.  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. 

Glen Zorn said:
I am strongly opposed to the publication of these documents as RFCs in their
current form.  Not only is the "fast provisioning" for EAP-FAST what can
only be characterized as a security disaster, but EAP-FAST-GTC has nothing
whatsoever to do with the EAP-GTC type.  EAP-GTC was "defined for use with
various Token Card implementations which require user input" but
EAP-FAST-GTC is used solely to transfer a username/password combination, the
password in plaintext.  It's hard to see what this has to do with actual
token cards & appears to be a lazy misuse of an existing type.  Furthermore,
it's even harder to see how rewarding this kind of nonsense with publication
will serve as a warning of any kind; I would expect that the action of
publication (with or without IESG note) would be more likely taken as notice
that one can do whatever one please without fear

David Mitton said:

I'm sorry,  I haven't responded earlier either, but I would like to pile on with some of my comments.
When I read the Cisco EAP-FAST GTC description and was similarly
shocked by the nature of the changes, and how poorly they technically
met their own rationale.
Encoding the "REQ=" and "RESP=" into Request and Response text, is
absolutely useless, since the data flow is unidirectional and known to
the requester/responder peers.
And then claiming that is more efficent because the username and OTP
are combined in one response, really ignores the issue that GTC doesn't
define what the appropriate response is.  And they did nothing to clue
the client as to what is being requested, or the format of the response.
Given that, a Client can only strip the useless cybercrud, and
continue with the normal GTC state machine which is let the user type
something in and send it.
A more robust OTP implementation may have several different inputs
that it wants from the user besides for username and OTP.  (BTW;
username could be derived from the EAP Identity)   There are possible
next token challenges,  new PIN assignment (user or system generated) 
and followup re-authentications.   Their protocol did nothing to codify
a standard for interoperation where a sequence of requests were
enumerated or named, and response items were described.  
I'm all for documenting practice, but this design/implementation
doesn't really seem to solve anything and just creates more confusion.
Dave Mitton
Dan Harkins said:

  I strongly recommend against publication of these two documents.
They represent essentially proprietary hacks on established protocols.
The benefit in documenting use of EAP in the Internet today is far
outweighed by the damage done to existing protocol specification and
implementations. They will serve only to create spagetti code and
unnecessary complexity.

  In addition to the issues noted by others I will also point out that
information is being extracted from TLS for use in (the exchange
erroneously described as) "EAP-MSCHAPv2" in a way that is different than
the way being proposed by the TLS WG and does not include a binding to
the application.

  I don't believe a stable reference of these proprietary hacks is
necessary because the lack of an RFC to reference them has not stopped
them from being implemented. Whatever process has been used in the
past to convey their specification can be used going forward.

  draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226
but nowhere in that RFC can I find description of the following label
for an initial assignment of repository values:

  "allocated for management by Cisco"

yet the draft instructs IANA to set aside values 11-63 for just that
purpose. I think that's very inappropriate. Not only is it telling IANA
to cede some of its authority to a large multinational corporation but
it is decidedly *NOT* documenting existing use! If this whole exercise
is to document existing use then where are the specifications for these
PAC attribute types?

  The recommended note does nothing to stop this kind of abuse in the
future because the pain you mention is not felt by the one doing
the abuse.

  To condone one transgression is to invite one thousand more.

  regards,

  Dan.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 5 Feb 2009 08:32:38 +0700

Bernard Aboba [mailto:[email-masked]] writes:

    codes."

 
I agree that a name change would be beneficial, but I'm much more concerned
about the pirating of EAP Type numbers: if we allow the same EAP Type codes
to be used for what are essentially different protocols, any pretense that
the IETF might have of promoting interoperability simply vanishes.

use within EAP-FAST. 

 
Well put, and two more good reasons to require the use of new & unique EAP
Types.

Glen Zorn said:

David Mitton said:

I'm sorry,  I haven't responded earlier either, but I would like to pile on
with some of my comments.
When I read the Cisco EAP-FAST GTC description and was similarly shocked by
the nature of the changes, and how poorly they technically met their own
rationale.
Encoding the "REQ=" and "RESP=" into Request and Response text, is
absolutely useless, since the data flow is unidirectional and known to the
requester/responder peers.
And then claiming that is more efficent because the username and OTP are
combined in one response, really ignores the issue that GTC doesn't define
what the appropriate response is.  And they did nothing to clue the client
as to what is being requested, or the format of the response.
Given that, a Client can only strip the useless cybercrud, and continue with
the normal GTC state machine which is let the user type something in and
send it.
A more robust OTP implementation may have several different inputs that it
wants from the user besides for username and OTP.  (BTW; username could be
derived from the EAP Identity)   There are possible next token challenges,
new PIN assignment (user or system generated)  and followup
re-authentications.   Their protocol did nothing to codify a standard for
interoperation where a sequence of requests were enumerated or named, and
response items were described.  
I'm all for documenting practice, but this design/implementation doesn't
really seem to solve anything and just creates more confusion.
Dave Mitton

Dan Harkins said:

unnecessary complexity.

the application.

PAC attribute types?

the abuse.

  regards,

  Dan.

---

From: <[email-masked]>
Date: Thu, 5 Feb 2009 08:33:46 +0100

I would like to remind everyone that these documents did go through
IETF Last Call, and have already been approved by IESG.

If folks are opposed to publishing descriptions of deployed EAP method
when they're less than perfect (or even ugly hacks with bad architecture),
and may not offer perfect security in all circumstances (but accurately
document their limitations), they should have said so much earlier.

(In hindsight, publishing these via the RFC Editor independent submission
route, and including the vendor's name in the document title, might
have been better idea. Since the intent was to describe what existing
implementations do, the IETF does not realistically have much change
control...)

Best regards,
Pasi

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Bernard Aboba
Sent: 04 February, 2009 21:25
To: [email-masked]
Subject: Re: [Emu] Potential Notes in EAP-FAST Documents

"

Glen Zorn said:

David Mitton said:

I'm sorry,  I haven't responded earlier either, but I would like to pile on with some of my comments.
When I read the Cisco EAP-FAST GTC description and was similarly shocked by the nature of the changes, and how poorly they technically met their own rationale.
Encoding the "REQ=" and "RESP=" into Request and Response text, is absolutely useless, since the data flow is unidirectional and known to the requester/responder peers.
And then claiming that is more efficent because the username and OTP are combined in one response, really ignores the issue that GTC doesn't define what the appropriate response is.  And they did nothing to clue the client as to what is being requested, or the format of the response.
Given that, a Client can only strip the useless cybercrud, and continue with the normal GTC state machine which is let the user type something in and send it.
A more robust OTP implementation may have several different inputs that it wants from the user besides for username and OTP.  (BTW; username could be derived from the EAP Identity)   There are possible next token challenges,  new PIN assignment (user or system generated)  and followup re-authentications.   Their protocol did nothing to codify a standard for interoperation where a sequence of requests were enumerated or named, and response items were described.
I'm all for documenting practice, but this design/implementation doesn't really seem to solve anything and just creates more confusion.
Dave Mitton

Dan Harkins said:

  regards,

  Dan.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 05 Feb 2009 11:01:27 +0200

Bernard,

> support version negotiation.

They should state this.

> Indeed, it would appear that some
> 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

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

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Feb 2009 01:02:56 -0800 (PST)

If the IESG doesn't want to hear opinions then maybe it shouldn't ask.
Since it did (this thread started with a post from "the IESG") then
it should listen to the opinions it solicited. With all due respect,
don't shut off this discussion with a "reminder" that these documents
went through IETF Last Call.

  The track of proposed publication really has nothing to do with my
comments (I can't comment on other people's comments). It is the content
of the documents, the haphazard manner in which they were constructed,
the disregard for standard ways of doing things they attempt to do,
and the blatant arrogance of the IANA considerations that really chaps
my hide.

  Can I instruct IANA to assign management of numbers in a newly created
registry to "The Daniel Harkins Trust"? No, probably not. I would expect
that  would generate lots of protests. And justifiably so. So let me ask
you (as a member of the IESG), why do you think it's OK to cede parts of
IANA's authority to Cisco Systems, Incorporated?

  Dan.

On Wed, February 4, 2009 11:33 pm, [email-masked] wrote:
> When I read the Cisco EAP-FAST GTC description and was similarly shocked
> by the nature of the changes, and how poorly they technically met their
> own rationale.
> Given that, a Client can only strip the useless cybercrud, and continue
> with the normal GTC state machine which is let the user type something in
> and send it.
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: <[email-masked]>
Date: Thu, 5 Feb 2009 10:34:57 +0100

Dan Harkins wrote:

>   If the IESG doesn't want to hear opinions then maybe it shouldn't
> ask.  Since it did (this thread started with a post from "the IESG")
> then it should listen to the opinions it solicited. With all due
> respect, don't shut off this discussion with a "reminder" that these
> documents went through IETF Last Call.

The IESG asked for comments about a very specific issue (proposed
notes to be added to these documents), not whether e.g. anonymous
provisioning is a good idea, or whether EAP methods with less than
ideal architecture should be published at all.

> comments (I can't comment on other people's comments). It is the
> content of the documents, the haphazard manner in which they were
> constructed, the disregard for standard ways of doing things they
> attempt to do, and the blatant arrogance of the IANA considerations
> that really chaps my hide.
>
>   Can I instruct IANA to assign management of numbers in a newly
> created registry to "The Daniel Harkins Trust"? No, probably not. I
> would expect that would generate lots of protests. And justifiably
> so. So let me ask you (as a member of the IESG), why do you think
> it's OK to cede parts of IANA's authority to Cisco Systems,
> Incorporated?

When a document creates a new number space, it can specify who
administers the numbers.  IANA's authority comes from a document
giving it the authority, not automatically.

IANA has no monopoly in this area, and for a vendor-proprietary
protocol,"The Daniel Harkins Trust" would indeed be acceptable.
Probably most vendor-specific RFCs don't give IANA any part of the
space (i.e., the vendor manages all the numbers) -- this is a bit
different since the range is partitioned, and it's possible to
get a number without the vendor approving.

We also have a number of IETF protocols where the numbers are not
administered by IANA. Many documents use registries maintained by ISO
or ITU-T.  Various documents from the SMIME and PKIX WGs use numbers
from a registry maintained by Russ Housley (as an individual
contributor, not as IESG member) instead of IANA. RPC program numbers
(used in e.g. NFS) are maintained by Sun Microsystems (although
there's ongoing work to move them to IANA). Probably other examples
exist.

Best regards,
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Thu, 05 Feb 2009 11:39:04 +0200

Pasi,

> document their limitations), they should have said so much earlier.

Indeed.

> implementations do, the IETF does not realistically have much change

Maybe we should focus on what to do next as opposed to figuring out what 
we should have done years ago. However, I think this would not have 
changed the substance of the matter, and per RFC 3932 the IESG would 
probably have noted that a non-IETF submission should not have an effect 
in an EAP type code defined by an IETF RFC (RFC 3748). So I think the 
document took the right path (and I still think it should be published), 
but we can of course wish that some of this discussion had happened in 
Last Call. That is, after all, what Last Calls are for :-)

Jari

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Feb 2009 01:50:00 -0800 (PST)

Hi Jari,

On Thu, February 5, 2009 1:39 am, Jari Arkko wrote:
[snip]
> we should have done years ago.

  Exactly! So let's, right now, decide to not publish these documents.

  Dan.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 5 Feb 2009 18:02:53 +0700

Pasi Eronen ([email-masked]) writes:

Given the quality of the documents in question, perhaps that's not something
that you should be bragging about.

No offense, but I'm getting the real feeling that you're just not paying
much attention.  The major problems I've heard WRT publication as-is have to
do with the misuse of IANA registries, not ugly hacks or "imperfect
security". 

control...)

Publishing them as individual submissions would have been a better idea I
don't see how that would solve the IANA problem.    

Best regards,
Pasi

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
Bernard Aboba
Sent: 04 February, 2009 21:25
To: [email-masked]
Subject: Re: [Emu] Potential Notes in EAP-FAST Documents

"

    codes."

use within EAP-FAST. 

Glen Zorn said:

David Mitton said:

Dan Harkins said:

unnecessary complexity.

the application.

PAC attribute types?

the abuse.

  regards,

  Dan.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 5 Feb 2009 19:17:50 +0700

...

> there's ongoing work to move them to IANA). Probably other examples

Ok, so now I'm totally confused.  None of the examples you cite are IANA
registries & I would have no problem w/Cisco handing out numbers for their
proprietary protocol, but that's not what they're doing.  What they're doing
is establishing an _IANA registry_ but retaining a significant portion of
that registry under proprietary control, presumably expecting IANA to
publish numbers at their behest.  Are you saying that's OK?

---

From: <[email-masked]>
Date: Thu, 5 Feb 2009 13:51:52 +0100

Glen Zorn wrote:

> > I would like to remind everyone that these documents did go
> > through IETF Last Call, and have already been approved by IESG.
>
> Given the quality of the documents in question, perhaps that's not
> something that you should be bragging about...
>
> > If folks are opposed to publishing descriptions of deployed EAP
> > method when they're less than perfect (or even ugly hacks with bad
> > architecture), and may not offer perfect security in all
> > circumstances (but accurately document their limitations), they
> > should have said so much earlier.
>
> No offense, but I'm getting the real feeling that you're just not
> paying much attention.  The major problems I've heard WRT
> publication as-is have to do with the misuse of IANA registries, not
> ugly hacks or "imperfect security".

I am paying attention, thank you. Of the emails on [email-masked] about
EAP-FAST in the past month or so, less than half of the text seems to
be about re-using EAP-GTC/MSCHAPv2 type codes. Your first email (Jan
27) mentions only anonymous provisioning (nothing about EAP type
codes), and your second message (Feb 3) first talks about the
insecurity of anonymous provisioning, and then about the EAP-GTC type
code.

The EAP-GTC type code re-use is not a new concern; it was specifically
discussed before the IESG approved the document, and the discussion
resulted in changes in the document. As far as I can tell, this thread
has contained no new information about the topic.  It seems you would
have preferred that IESG had reached a different decision back
then. That's a perfectly valid opinion, but the IETF Last Call
would have been the right time to express it.

For EAP-MSCHAPv2, I think there has been some new information that
wasn't really well considered before IESG approved the document.
IESG is proposing solving it basically the same way as for EAP-GTC --
noting that this is bad design, and future design should not do it
this way.

> > (In hindsight, publishing these via the RFC Editor independent
> > submission route, and including the vendor's name in the document
> > title, might have been better idea. Since the intent was to
> > describe what existing implementations do, the IETF does not
> > realistically have much change control...)
>
> Publishing them as individual submissions would have been a better
> idea I don't see how that would solve the IANA problem.

BTW, you can look at this either as changing an existing code point,
or defining a field (an EAP-FAST TLV "Value" part) that contains
either protocol X (normal EAP header with IANA-allocated EAP Type
code) or protocol Y (some other stuff).

Basically, the change that was made to draft-zhou-emu-fast-gtc says
"if this byte contains anything else than 0x06, interprete it as
normal EAP Header with IANA-allocated EAP Type number. If it contains
0x06, interprete it as described below." (not using those words, but
that's the idea)

When some field can contain either X or Y, normally we'd multiplex
them by having a separate "type" field outside the field itself.
That's the approach used in e.g. RFC5281, which changes MS-CHAPv2
challenge processing in very similar way as draft-cam-winget-eap-
fast-provisioning.

Another approach is to multiplex by "peeking inside the content";
while this is usually less preferable, it's a choice the protocol
designer gets to make when defining a new field (and is used in
some IETF specs too; e.g. draft-ietf-avt-dtls-srtp).

Choosing this approach to multiplexing the contents of this field
certainly was not a good design decision, and the proposed IESG text
basically says so (and warns that it probably doesn't exactly
simplify implementation either). But I don't think it should alone
prevent publishing a description of somewhat widely implemented protocol.

*IF* this caused interoperability problems for folks who don't
implement this specification (or between folks who do implement
this spec and those that don't), I'd be very worried indeed.
But that does not seem to be the case.

Best regards,
Pasi

---

From: <[email-masked]>
Date: Thu, 5 Feb 2009 14:01:56 +0100

Glen Zorn wrote:

> Ok, so now I'm totally confused.  None of the examples you cite are
> IANA registries & I would have no problem w/Cisco handing out
> numbers for their proprietary protocol, but that's not what they're
> doing.  What they're doing is establishing an _IANA registry_ but
> retaining a significant portion of that registry under proprietary
> control, presumably expecting IANA to publish numbers at their
> behest.  Are you saying that's OK?

Ah -- my understand was that Cisco is not expecting IANA to publish
anything at their behest; IANA will just mark 11-63 as "Allocated for
Cisco", and if Cisco wants to use any of those numbers, they don't
need to tell IANA.

Or in other words, I thought IANA would operate the registry just like
any other IANA registry with "Specification Required" policy, except
the free values are 64-255.

(I think this approach, while perhaps a bit unusual, is better than
the normal "can't extend the protocol unless vendor agrees" approach.)

Best regards,
Pasi

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 5 Feb 2009 20:21:47 +0700

> the free values are 64-255.

Hmm.  OK, that's not an unreasonable interpretation but in that case I don't
understand why 1) the first 10, 3, whatever numbers are doing in the
registry at all, since their status as proprietary allocations are just the
same as the next set & 2) why the document doesn't just say that the range
is reserved.  "Managed by Cisco" implies to me that Cisco plans to allocate
the number themselves (presumably as a convenience & to avoid the pain
(embarrassment?) of publishing an RFC every five minutes), then advertise
them using IANA.  Since I've been wrong before, though ;-), I'd be
interested in hearing from the authors on this subject.

...

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Feb 2009 11:17:10 -0800 (PST)

Hi Pasi,

> Cisco", and if Cisco wants to use any of those numbers, they don't

  So if I want to make a proprietary hack to this protocol I must have
a public specification reviewed by a Designated Expert while Cisco can
make proprietary hacks to their heart's content. And this arrangement is
enforced by the Internet Assigned Numbers Authority.

  Where in RFC 5226 does it mention this sort of arrangement?

  This whole snafu is because Cisco is abusing numbers assigned by IANA.
They make proprietary hacks to established protocols, claim universal
support for their hacks, and use that claim to get something published
that should never be published.

  And we're going to publish a note lamenting the fact that this
happened ("If EAP-FAST were designed today, these difficulties could be
avoided....") while we basically ensure it will happen again!

  It's like telling an alcoholic not to drink while you give him a
gift certificate from a liquor store.

  Dan.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 5 Feb 2009 14:27:39 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Jari Arkko
Sent: Thursday, February 05, 2009 1:01 AM
To: Bernard Aboba
Cc: [email-masked]
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.

> members of the IESG think that method overloading is required by EAP 
> tunneling methods desiring to incorporate support for cryptographic 
> binding.

> Would the IESG use the same words to describe the reuse of IP protocol

> numbers within an IP tunnel?  I doubt it.

Jari

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 6 Feb 2009 10:48:52 +0700

> insecurity of anonymous provisioning, and then about the EAP-GTC type

Indeed, my initial comments were admittedly more appropriate to the topic of
an IESG note; the misuse of EAP type codes can't be fixed with a note,
though.

> would have been the right time to express it.

I just have to ask: if the purpose of IESG review is not to catch problems
missed in IETF Last Call, what is it?

> simplify implementation either). 

Possibly one of the most important things I learned in college was what
people _say_ most often has little to do with what they actually believe: to
find out what people really believe you much look at their actions (OK, a
simple but somewhat stronger variant of "actions speak louder than words"
;-).  In this case, what the authors have done is ignore not just IETF
process but the simplest rules of protocol design & what the IESG is
proposing to _do_ is confirm that that's just fine.  Your proposed note is
essentially irrelevant.  It might not be if it addressed the correct issues
with the draft instead of rationalizing the misuse of type codes.

> But I don't think it should alone

OK, then change the numbers; doing so doesn't modify the the protocol at
all.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 6 Feb 2009 17:11:09 +0700

> difficulties
> difficult before RFC 3748 defined expanded EAP Types.  

Uh-huh.  The extremely onerous & time-consuming FC,FS allocation policy...

> The reuse may

This is getting tiresome.  Given your obvious & continuing disdain for both
the recipients of your messages (do you think that nobody on this list ever
requested an EAP Type code pre-3748?) & the IETF in general, combined with
the poor quality of the documents themselves, I will have to agree with
Dan's assertion & ask that these documents not be published & that the
existing IANA registries be removed.  I'm sure that Cisco's marketing
department can continue its fine job of publicizing EAP-FAST & you can just
run your very own registry of EAP-FAST numbers.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 6 Feb 2009 15:25:12 -0500

I think assigning a new EAP Type for an existing EAP method with
different usages intended for a particular tunneling method is a bad
idea.  Can we avoid it?

Since the Intended status of this draft is Informational, I think
adding an IESG Note describing the issue recognized by the IESG may be
ok.

Thanks,
Yoshihiro Ohba

---

From: Tim Polk <[email-masked]>
Date: Wed, 11 Feb 2009 09:26:14 -0500

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

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 11 Feb 2009 10:14:55 -0800 (PST)

This looks like a good resolution. Thanks Tim.

Gabriel

----- Original Message ----
> From: Tim Polk <[email-masked]>
> To: [email-masked]
> Cc: "[email-masked] IESG" <[email-masked]>
> Sent: Wednesday, February 11, 2009 6:26:14 AM
> 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
> 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
>     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,
>     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.
> 
>     incompatible with EAP method negotiation as defined in RFC 3748.  Since
>     EAP-GTC does not support method-specific version negotiation,  the use of
>     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
>     difficulties could be avoided by utilization of unique EAP Type codes.
> I am not under the illusion that this text will be entirely satisfactory to 
> anyone,

---

From: Jouni Malinen <[email-masked]>
Date: Wed, 11 Feb 2009 22:13:20 +0200

> path for future protocol developers.

This looks like an appropriate text to add. However, I would request a
small clarification on the exact scope of the different EAP-MSCHAPv2 and
EAP-GTC behavior. As far as EAP-FAST-MSCHAPv2 vs. EAP-MSCHAPv2 is
concerned, I would expect that EAP-FAST-MSCHAPv2 is actually used both
for unauthenticated (anonymous) and server-authenticated provisioning
while the proposed note seemed to indicate that the different behavior
is implied by the use of an anonymous tunnel. See below for suggested
changes to resolve this.

I'm assuming that the implicit challenges derived from the TLS handshake
are not used in the EAP-FAST authentication, i.e., normal authentication
would be using something that is closer to EAP-MSCHAPv2, not
EAP-FAST-MSCHAPv2. However, I think that even that use of EAP-MSCHAPv2
differs a bit from the way it is used in other protocols, e.g., as far
as key derivation is concerned, but this would have been more of a
comment for RFC 4851 than these two drafts that are now discussed.
Anyway, since the key derivation from inner method is used also during
provisioning, it would be useful to specify the exact process used to
derive ISK from EAP-FAST-MSCHAPv2 (especially the order of send/recv
MS-MPPE keys which seems to differ from the way this is used in PEAPv0
with cryptobinding).

>     EAP-MSCHAPv2 (26) for authentication within an anonymous TLS tunnel.  

s/an anonymous TLS tunnel/the EAP-FAST tunnel during provisioning/

> In

This use of "anonymous tunnel" sounds fine.

>     EAP-FAST tunnel.

s/of an anonymous EAP-FAST tunnel/inside the EAP-FAST tunnel during
provisioning/

>  This behavior may cause problems in  
> implementations
>     method.

That "anonymous" should likely be replaced, too, but I don't have a good
proposal for this one. Maybe s/an anonymous/the/

The implementation complexity comes both from different tunneling
methods using different versions of EAP-MSCHAPv2 and from the different
use within EAP-FAST depending on state (provisioning vs.
authentication).

> Since
>     authentication.

s/ during authentication//

I'm not sure whether this "during authentication" was referring to the
case where EAP-FAST provisioning is not used (i.e., normal
authentication after PAC has been previously provisioned). Anyway, it is
probably clearer to just specify that EAP-FAST-GTC is used in all cases
inside EAP-FAST tunnel since the draft seems to indicate that this is
indeed the case (just note that EAP-FAST-GTC is not allowed in
unauthenticated/anonymous provisioning, but it is allowed in
server-authenticated provisioning).

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 12 Feb 2009 08:25:52 +0700

> publications do not establish precedent for future reuse of EAP type

I'm sure that the IESG views its essentially invertebrate response to this
outrageous behavior as stern but fair.  If this pirating of IANA allocated
parameters is actually allowed (as it appears that it will be), I suggest
that you keep this stern warning around (perhaps as a form-letter template
so you can easily fill in the blanks); even better, publish it (suitably
modified for generality) as an RFC so the next few hundred "designers" who
can't be bothered with IANA can just reference it.

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Wed, 11 Feb 2009 22:05:57 -0500

Jouni:

Thanks for the feedback.

To clarify, EAP-FAST-MSCHAPv2 is only being used during anonymous
provisioning mode, in other cases, the normal EAP-MSCHAPv2 is being
used. This is mentioned in draft-cam-winget-eap-fast-provisioning
Section 3.2.3 and reflects current implementations. The design is to
specifically minimize the risk associated with an anonymous tunnel,
which does not apply to an authenticated tunnel.  

As for the ISK derivation from EAP-MSCHAPv2, a further clarification is
probably helpful. As discussed, EAP-MSCHAPv2 documentation doesn't
really describe how MSK is generated, only referencing RFC3079. RFC3079
only describes how two 128-bit keys are generated, but leaves out how
these two keys are combined to form the MSK. This leaves it to be
defined in a tunnel method specific way. It seems that EAP-FAST may have
defined a combining algorithm different with the other method. 

Here is what we propose to add to draft-cam-winget-eap-fast-provisioning
Section 3.2.3 to clarify the issue. 

"The inner session key (ISK) generation for EAP-FAST-MSCHAPv2 and
EAP-MSCHAPv2 used inside EAP-FAST MUST follow the steps below. Two 128
bit master keys MasterSendKey and MasterReceiveKey are generated
according to the RFC3079. They are combined to form the ISK, with
MasterSendKey taking the first 16 octets and MasterReceiveKey taking the
last 16 octets. "

As for the GTC comment, you are right that EAP-FAST-GTC is being used in
all cases inside EAP-FAST. So your suggestion of removing "during
authentication" or changing it to "always" is fine.  

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jouni Malinen
> Sent: Wednesday, February 11, 2009 3:13 PM
> To: Tim Polk
> Cc: [email-masked]; [email-masked] IESG
> > documents.  The notes clearly state the drawbacks for EAP type code 
> > reuse and define an acceptable path for future protocol developers.
> 
> This looks like an appropriate text to add. However, I would 
> request a small clarification on the exact scope of the 
> different EAP-MSCHAPv2 and EAP-GTC behavior. As far as 
> EAP-FAST-MSCHAPv2 vs. EAP-MSCHAPv2 is concerned, I would 
> expect that EAP-FAST-MSCHAPv2 is actually used both for 
> unauthenticated (anonymous) and server-authenticated 
> provisioning while the proposed note seemed to indicate that 
> the different behavior is implied by the use of an anonymous 
> tunnel. See below for suggested changes to resolve this.
> 
> I'm assuming that the implicit challenges derived from the 
> TLS handshake are not used in the EAP-FAST authentication, 
> i.e., normal authentication would be using something that is 
> closer to EAP-MSCHAPv2, not EAP-FAST-MSCHAPv2. However, I 
> think that even that use of EAP-MSCHAPv2 differs a bit from 
> the way it is used in other protocols, e.g., as far as key 
> derivation is concerned, but this would have been more of a 
> Anyway, since the key derivation from inner method is used 
> also during provisioning, it would be useful to specify the 
> exact process used to derive ISK from EAP-FAST-MSCHAPv2 
> (especially the order of send/recv MS-MPPE keys which seems 
> to differ from the way this is used in PEAPv0 with cryptobinding).
> 
> s/of an anonymous EAP-FAST tunnel/inside the EAP-FAST tunnel 
> during provisioning/
> 
> >  This behavior may cause problems in implementations
> That "anonymous" should likely be replaced, too, but I don't 
> have a good proposal for this one. Maybe s/an anonymous/the/
> 
> The implementation complexity comes both from different 
> tunneling methods using different versions of EAP-MSCHAPv2 
> and from the different use within EAP-FAST depending on state 
> (provisioning vs.
> authentication).
> 
> 
> >     EAP-GTC does not support method-specific version 
> negotiation,  the 
> > use of
> I'm not sure whether this "during authentication" was 
> referring to the case where EAP-FAST provisioning is not used 
> (i.e., normal authentication after PAC has been previously 
> provisioned). Anyway, it is probably clearer to just specify 
> that EAP-FAST-GTC is used in all cases inside EAP-FAST tunnel 
> since the draft seems to indicate that this is indeed the 
> case (just note that EAP-FAST-GTC is not allowed in

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Feb 2009 13:19:04 -0800

> is to document existing use then where are the specifications for these

It would appear that the registry of "EAP-FAST PAC Attribute Types" relates
to a Standard Track document, RFC 4507, although the document itself
doesn't indicate that it updates RFC 4507.

RFC 5226 does permit vendor-specific registries, although it is somewhat odd to
enable vendor extensions for only one vendor, particularly if this does relate to
an IETF standards track document (which would imply IETF change control, no?)

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 12 Feb 2009 12:29:58 +0700

Hi, Bernard.  I can't find anything in 5226 that says anything about
vendor-specific registries.  Can you send a quote?

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernard Aboba
Sent: Thursday, February 05, 2009 4:19 AM
To: [email-masked]
Subject: Re: [Emu] IANA allocation issue in EAP-FAST Documents

RFC 5226 does permit vendor-specific registries, although it is somewhat odd
to

enable vendor extensions for only one vendor, particularly if this does
relate to

an IETF standards track document (which would imply IETF change control,
no?)

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 11 Feb 2009 23:14:07 -0800 (PST)

Hi Bernard,

  "odd" isn't the word I'd use to describe it. Audacious and hubristic
are a bit more like it.

  These aren't "private use" or vendor-specific attributes. Let's be
very specific about that.

  I don't understand your mention of modifying RFC 4507. Is this yet
another problem with these drafts?

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 11 Feb 2009 23:21:55 -0800 (PST)

Maybe we should just update RFC 5226 to add "allocated for management
by Cisco" to the list of labels for initial assignment. Then other RFCs
could give a block of numberspace to Cisco and we wouldn't have the
kind of problem being caused by these drafts. Cisco wouldn't need to
steal an already-assigned value for whatever weird proprietary hack they
want to do, they can just take one from their own numberspace.

  Dan.

---

From: Jouni Malinen <[email-masked]>
Date: Thu, 12 Feb 2009 10:30:16 +0200

> which does not apply to an authenticated tunnel.  

Thanks. Apparently, I looked at my implementation bit too quickly and
assumed it was using the implicit challenges for both provision cases,
but you are correct, the draft does indeed state this only for anonymous
provisioning and I now confirmed that that was also what my
implementation was doing. In other words, the changes I asked for the
note for draft-cam-winget-eap-fast-provisioning for the topic of when to
use EAP-MSCHAPv2 vs. EAP-FAST-MSCHAPv2 should not be made and only the
change request for draft-zhou-emu-fast-gtc would be suitable.

> defined a combining algorithm different with the other method. 

I agree for the part that MSK derivation for EAP-MSCHAPv2 is not very
well defined and it did require going through multiple documents to
figure out the order.

As far as MSK derivation for an inner method being tunnel method
specific is concerned, I do not agree with that. It should be up to the
inner method specification to define how MSK is derived and tunnel
method ISK should just use that MSK.

I do not remember anymore where exactly I found this, but probably
based on the MSCHAPv2 documents and the way MS-MPPE keys are used in
other methods, I ended up with EAP-MSCHAPv2
    MSK = server MS-MPPE-Recv-Key | server MS-MPPE-Send-Key

This is the order used in EAP-PEAPv0 cryptobinding derivation.

In EAP-FAST, the opposite order is used:
    MSK = server MS-MPPE-Send-Key | server MS-MPPE-Recv-Key

> MasterSendKey taking the first 16 octets and MasterReceiveKey taking the

Taken into account that MasterSendKey in RFC 3079 is defined as the
server MS-MPPE-Send-Key, this matches with the order I described above
and including this note in the draft would indeed be a helpful
clarification.