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.i...@… | Owner: yaronf.i...@…
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.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
