Subject: [IPsec] #188: Explicit list of allowed EAP methods]

From: Yaron Sheffer <[email-masked]>
Date: Mon, 12 Apr 2010 18:34:58 +0300

Hi,

there was some off-line discussion on whether the mutual-EAP auth draft
should explicitly list the EAP methods that work, securely, with this
extension. I now tend to say no, and to remove this list (and IANA
registry) from the next document rev. This issue summarizes the
discussion.

Thanks,
	Yaron

#188: Explicit list of allowed EAP methods
-----------------------------------+----------------------------------------
 Reporter:  yaronf.ietf@…          |       Owner:  yaronf.ietf@…        
     Type:  defect                 |      Status:  new                  
 Priority:  normal                 |   Milestone:                       
Component:  eap-mutual             |    Severity:  Active WG Document   
 Keywords:                         |  
-----------------------------------+----------------------------------------
 Rev -00 has a list of allowed methods, as a document section and a
future
 IANA registry.

 Pros:

  * Vendors do not have to decide which methods are suitable - which may
be
 error prone.
  * Some methods may be suitable only under certain conditions (e.g.
only
 one variant of EAP-POTP is suitable, incidentally this happens to be
the
 variant actually implemented). This is a place to document these
 restrictions.

 Cons:

  * EAP is a major interface into the AAA. Limiting the number of
methods
 restricts this interface.
  * EAP methods (in particular tunnel methods) are used to convey
 additional info, e.g. posture. So even though some of them look weird
in
 this context, because they might require server certs, they might make
 sense all the same.
  * Security can eventually depend on tunnel-internal EAP methods, which
we
 will probably not document here.
  * Extra bureaucracy implied by the IANA registry.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Apr 2010 08:42:05 -0700

At 6:34 PM +0300 4/12/10, Yaron Sheffer wrote:
>registry) from the next document rev.

The list is not just "methods we like" but also "methods that are known to have the properties that are required to be safe here, because some other methods don't have those properties".

A different proposal would be to leave the list in as "the authors think that these methods (and likely others) should be considered as safe", but not to have the IANA registry, letting developers pick what to include (including known-unsafe ones).

--Paul Hoffman, Director
--VPN Consortium

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 14 Apr 2010 09:48:27 +0300

> The list is not just "methods we like" but also "methods that are known
> to have the properties that are required to be safe here, because some
> other methods don't have those properties".
> 
> A different proposal would be to leave the list in as "the authors
> think that these methods (and likely others) should be considered as
> safe", but not to have the IANA registry, letting developers pick what
> to include (including known-unsafe ones).

Or, just list the required "properties", and name some methods as examples.

Alper

> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec