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

["Glen Zorn" <[e-mail]>]

[e-mail] [mailto:[e-mail]] writes:

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

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.

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

I just have to ask: if the purpose of IESG review is not to catch problems
missed in IETF Last Call, what is 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). 

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
> prevent publishing a description of somewhat widely implemented
> protocol.

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

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