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

[<[e-mail]>]

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 [e-mail] 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