Subject: [eap] Draft EAP BOF Minutes

From: [email-masked] (Bernard Aboba)
Date: Sun, 24 Mar 2002 21:03:13 -0800 (PST)

Here are the draft EAP BOF minutes:

http://www.drizzle.com/~aboba/EAP/eapbof.txt

Here are the presentations:

http://www.drizzle.com/~aboba/EAP/presentations.zip

---

From: [email-masked] (Darran Potter)
Date: Wed, 27 Mar 2002 12:07:58 -0000

Bernard

Since there were no issues raised with EAP-MSCHAP-V2 last week do you
forsee any reason why this draft cannot be advanced to an RFC?

Thanks
Darran 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Bernard Aboba
> Sent: 25 March 2002 05:03
> To: [email-masked]
> Subject: [eap] Draft EAP BOF Minutes
> 
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (David Jablon)
Date: Wed, 27 Mar 2002 14:04:21 -0500

>forsee any reason why this draft cannot be advanced to an RFC?

EAP-MSCHAP-V2?

Sure, Bernard, let's rush EAP-MSCHAP-V2 through the process
before any security requirements for EAP methods are nailed down.
We really need this since we don't want people to get the notion
that maybe these "industry standard" 20-year-old protocols
merely provide the illusion of cryptographic security.

No issues?  How about these:

* CHAP, even this version, has the approximate cryptographic security
   of clear-text passwords.

* Every run of CHAP gives an eavesdropper sufficient information
  to verify password guesses off-line to his heart's content.

* The security note about "cryptanalysis" is a smokescreen,
  and confuses "cryptanalysis" with "popular science".

* The warning: "a major issue is the use of weak passwords",
   where "weak" == "most", is worthy of a cigarette pack.

No issues?  Can you say "grossly irresponsible"?
And to think that I thought that the "CHAP == crap" slide at the
EAP BOF might have some impact ...

Whew.  I'm OK now.

To be fair and constructive, this protocol might have its uses,
so I'll suggest a short paragraph that can be added to the draft
www.ietf.org/internet-drafts/draft-dpotter-pppext-eap-mschap-01.txt
to help clarify the situation for the alert reader:

        "Regardless of any other discussion herein, this protocol provides
        essentially no cryptographic security for its stated purpose of
        password-based authentication.  It would be irresponsible
        to use this protocol unless all protocol messages are otherwise
        secured to be confidential between the intended participants."

Apologies for the rant.

-- David

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Mar 2002 06:38:24 -0800 (PST)

> >forsee any reason why this draft cannot be advanced to an RFC?

IETF 53 method presentations were limited to a single slide, so there
wasn't really an opportunity to review any of the methods -- just enough
time to describe what they were attempting to achieve. 

What kind of review are you looking for? A security analysis? An EAP
issues review?

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 27 Mar 2002 16:51:25 -0500

> merely provide the illusion of cryptographic security.

I don't think Bernard was suggesting anything like this.  Where did you get
this idea?

John

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Mar 2002 13:46:41 -0800 (PST)

> I don't think Bernard was suggesting anything like this.  Where did you get

Indeed, I didn't post the message to which this paragraph refers, so it
would appear that the poster got confused about who he was responding to. 

More to the topic, though, RFC 2284 as it stands doesn't specify a review
process for EAP methods. It's first come, first served. The major effect
of this so far is that methods that are vendor-specific with no spec are
being allocated global code points. The point of the IANA Considerations
discussion was to figure out whether that was appropriate, or whether
vendor-specific methods should use their own vendor-specific space (such
as Method 255)

As I see it, we have several choices:

a. Leave things as they are. The danger with this is that we could exhaust
the EAP space in a few years. 

b. Allocate Types just based on a spec, no expert review. This would
presumably cause vendor-specific methods to move over to the
vendor-specific space, accomplishing the goal of easing pressure on the
global space. It would not do anything to improve the quality of published
EAP methods however. 

c. Allocate Types based on "Expert Review" with specification. This is the
current proposal. This slows down the allocation of the global spec, but
adds work to the EAP WG. 

d. Allocate Types based on "Designated Expert" with spec. This slows down
allocation, and keeps work out of the WG at large, but dumps it on
designated experts who will be presumably hard to find. 

At the BOF, we talked about requiring "Expert Review" with
specification. This particular proposal raises some questions:

a. Assuming that the EAP WG is the review body, what are we reviewing it
for? Security? Correct use of EAP? Do we need guidelines about how the
review will be conducted and what we are looking for? If so, who will
write those guidelines? 

b. How do we determine the outcome of the review? By individual WG members
sending some comments? Expert Review as used by the RADIUS WG just meant
sending some mail to the radius mailing list and incorporating comments
raised there. Are we looking for something more? 

c. Can a spec "fail" review? If so, does someone tell IANA not to allocate
a Type until the issues are fixed? 

d. If we do intend to review the security of methods (shudder), how do we
find the expertise to carry out such a review? 

e. Even if all we're doing is reviewing the correct use of EAP, is it
reasonable to expect an EAP WG to be doing this while at the same time
trying to forge ahead with new work? Or would the WG likely to get bogged
down in reviews?

---

From: [email-masked] (David Jablon)
Date: Wed, 27 Mar 2002 23:29:39 -0500

Yes, I sarcastically wrote:
>> > Sure, Bernard, let's rush EAP-MSCHAP-V2 through the process ...

>would appear that the poster got confused about who he was responding to. 

Sorry about that.  Chalk it up to poorly aimed sarcasm.  I should know better.

The ridicule was really intended for the draft in question, and at the
*request* to advance its status as a standard, and not to any action
of Bernard's in this group.

>More to the topic, though ...

Some thoughts on that to come in a separate reply.

-- David

---

From: [email-masked] (David Jablon)
Date: Wed, 27 Mar 2002 23:58:53 -0500

At 01:46 PM 3/27/02 -0800, Bernard Aboba wrote:
>process for EAP methods. ...
>a. Leave things as they are. The danger ... is [exhausting the EAP space]
>b. Allocate Types just based on a spec, no expert review. ...
>c. Allocate Types based on "Expert Review" with specification. ...
>d. Allocate Types based on "Designated Expert" with spec. ...

I think the bigger danger is having EAP method documents written in a highly 
inconsistent manner, leading to extreme confusion over exactly
what security properties are provided, and their relative significance.

Group review could at least help to insure some consistency in the
security considerations section of these related documents.
Hence my earlier sarcastic comments.

Something like (c) seems acceptable.

>specification. This particular proposal raises some questions: ...

To start, I'd suggest that review for *consistency* of security discussion
be a primary goal.

For example, a method that requires a separately negotiated quantum
channel to be secure might be just fine, as long as the description is
very clear on what it takes to make it secure.

>raised there. Are we looking for something more? 

WG list comments would be a fine start.

>find the expertise to carry out such a review? 

The WG should not shudder at the task of reviewing security.  Presumably,
every author who proposes an EAP method has reviewed it's security
properties against some kind of threat model to insure that it works
as advertised.  This naturally creates a body of expertise in the WG.

>trying to forge ahead with new work? Or would the WG likely to get bogged

The value of EAP as a framework seems directly related to the value
of the resulting product.  If it takes WG effort to make that product
consistent, understandable, easy to use, etc., so be it.

-- David

---

From: [email-masked] (John Schnizlein)
Date: Wed, 27 Mar 2002 18:53:09 -0500

At 11:29 PM 3/27/2002, David Jablon wrote:
>...  Chalk it up to poorly aimed sarcasm.  I should know better.
>
>The ridicule was really intended for the draft in question, 

You might find useful advice in the Plenary presentation:
Miss Manners Meets the IETF
http://www.ietf.org/proceedings/02mar/slides/plenary-3/index.html

Hint: sarcasm and ridicule are not the way the IETF is supposed to work.

John

---

From: [email-masked] (Glen Zorn)
Date: Wed, 27 Mar 2002 17:49:11 -0800

David Jablon [mailto:[email-masked]] writes:

> *request* to advance its status as a standard,

There was no "request" to advance the draft to standard, if for no other
reason than that Bernard has no say whatsoever is approving or disapproving
such an action.  Given that, I confess that I don't understand the
motivation behind the original message, but I do know that virtually nothing
in your response made sense, since (as Bernard pointed out) there are
currently no requirements (security-related or otherwise) for the allocation
of EAP type numbers by IANA, let alone the publication (as RFCs) of
documents describing EAP types.

> and not to any action

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Mar 2002 17:29:14 -0800 (PST)

> There was no "request" to advance the draft to standard, 

As I understand it, the draft is intended to be Informational, and says
so, right on the first page. 

> if for no other reason than that Bernard has no say whatsoever is
> approving or disapproving such an action.  

Indeed. To publish an individual submission as an Informational RFC, one
has only to ask the RFC editor to do so, and get approval from the IESG. 
I am not involved, nor do I want to be; I can think of no more horrible
punishment than being made the default "designated expert" for review of
dozens of EAP methods. And having served on the nomcom for 4 of the last 5
years, I know of a good form of torture when I see it :)

> Given that, I confess that I don't understand the

And after this exchange, I must say that letting it stay that way is
beginning to look appealing.

---

From: [email-masked] (David Jablon)
Date: Thu, 28 Mar 2002 02:43:40 -0500

I agree.  It would be a bad idea to designate any single expert
to do the job, or to expect anyone to want that job.

>years, I know of a good form of torture when I see it :)

What is needed is a simple peer-review communal process.
Open publication, gather feedback from the group, and have a designated
moderator to help resolve disputes (and squelch the occasional rude remarks).
If no new criticism arrives within a designated period, off it goes.

I don't think it requires a huge individual effort on any one person's part
to make this kind of thing work.

-- David

---

From: [email-masked] (Simon Josefsson)
Date: Thu, 28 Mar 2002 11:56:27 +0100

> what security properties are provided, and their relative significance.

As long as they aren't published on the Standards Track, I don't see
what harm this causes [1].  You aren't forced to implement all IANA
registered EAP mechanisms.  There is no "seal of approval" from IETF
or the EAP working group on proprietary EAP mechanisms, and even if
there was it is not clear what such a seal of approval would be worth.
In my humble opinion, we have limited resources to review documents,
and spending them on reviewing non-standards track proprietary
solutions is not a good idea.  It is better to spend our time to
review the core EAP spec and any core EAP mechanisms instead.

Compare the situation with TLS cipher suites, by not giving up control
over cipher suites to IANA, the TLS WG will have to carry on forever
reviewing new cipher suite proposals.

Of course I wish that everyone allocating EAP mechanisms with IANA
would write an I-D and send it to this group, but my stand is that
this group should not be forced to take any action.

[1] Except for possibly EAP type number space exhaustion, but this
single problem is years ahead and can be solved by expanding the EAP
range now.

---

From: [email-masked] (Luca Salgarelli)
Date: 28 Mar 2002 10:22:05 -0500

> If no new criticism arrives within a designated period, off it goes.

I would agree with this. 

I also think that EAP type numbers allocated by IANA should be reserved
for methods that have gone through some form of peer review in the IETF.
Proprietary methods that don't go through this should use a
vendor-specific type code, and be published as informational.

Thanks
Luca