Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods
draft-ietf-emu-chbind-16

[Ballot discuss]
(Sorry, I ran out of time to properly consider the secdir review
so I'll just trust that that's being handled correctly.)

1) cleared

2) p22, 9.1 says "derivation of keying material including a key for
integrity protection of channel binding messages" but that doesn't say
that it must be that the authenticator can't know the relevant key.
There also seems to be a missing MUST in the lead in to that list.

3) cleared

[Ballot comment]
1) The secdir review [1] has resulted in some changes that are already
agreed and some that are being chatted about between reviewer and wg
chair. This is just a discuss to hold things while that happens. (Not
all the review comments are DISCUSS level, but a few are. We can
figure out which if we get stuck on some if that's ok.)

  [1]
http://www.ietf.org/mail-archive/web/secdir/current/msg03271.html

2) Does this really work with ERP? Seems like it'd add more
roundtrips, e.g. making ERP-AAK pointless.

3) Why can't the authenticator cheat on CB if the EAP method is based
on symmetric crypto with a KDC like thing? In fig 1 the lying NAS
could mess with i1 as sent from peer to server.  Why not?

4) Does including attributes that were validated in the CB failure
message not expose the server to someone probing the server's policy?
E.g. the lying NAS could play about until it knows what cheating is
possible?

5) What does "MAY be defined" mean in 7.1? By whom? Where?  Does that
need to be here?

6) What does "as thorough of a validation as possible" mean in section
8? That doesn't seem to be testable.

7) Is "typically contains" enough for User-Name protection if EAP
method identity protection is employed? I expected to see a MUST
there.

8) Is A.3 correct? If the selected method is breakable (if not why
bid down to it?) then the bad NAS can probably change the i1 message
so I'm not convinced by this argument.

nits:

- p10 - rfc5296bis is in IESG Evaluation, and obsoletes 5296 so you
should update the reference

- p11 - knowing that the client is using layer 2 crypto doesn't seem
very compelling if concerned about a bad NAS, since its the often the
case that the putative bad NAS that can see the plaintext, it could
leak that back over the air in clear if it wanted. (Liable to be
detected, but then so might lack of layer2 crypto in the client UI.)

- p22 - the NAS identifier can expose the user's location, depending
on how those are named and whether confid. is available for the
peer/server i1 or i2 message. That might be worth a mention.

[Ballot discuss]

(Sorry, I ran out of time to properly consider the secdir review
so I'll just trust that that's being handled correctly.)

1) Can't a lying NAS bid down the EAP methods available?  Is it really
likely that a peer will prefer CB over network connection? (p16) 9.3
seems to recognise this problem, but doesn't solve it.

2) p22, 9.1 says "derivation of keying material including a key for
integrity protection of channel binding messages" but that doesn't say
that it must be that the authenticator can't know the relevant key.
There also seems to be a missing MUST in the lead in to that list.

3) Is it not possible to specify some EAP methods that can be
used with this? If not, then I'm confused as to how this document
is to be used.

[Ballot comment]

1) The secdir review [1] has resulted in some changes that are already
agreed and some that are being chatted about between reviewer and wg
chair. This is just a discuss to hold things while that happens. (Not
all the review comments are DISCUSS level, but a few are. We can
figure out which if we get stuck on some if that's ok.)

  [1]
http://www.ietf.org/mail-archive/web/secdir/current/msg03271.html

2) Does this really work with ERP? Seems like it'd add more
roundtrips, e.g. making ERP-AAK pointless.

3) Why can't the authenticator cheat on CB if the EAP method is based
on symmetric crypto with a KDC like thing? In fig 1 the lying NAS
could mess with i1 as sent from peer to server.  Why not?

4) Does including attributes that were validated in the CB failure
message not expose the server to someone probing the server's policy?
E.g. the lying NAS could play about until it knows what cheating is
possible?

5) What does "MAY be defined" mean in 7.1? By whom? Where?  Does that
need to be here?

6) What does "as thorough of a validation as possible" mean in section
8? That doesn't seem to be testable.

7) Is "typically contains" enough for User-Name protection if EAP
method identity protection is employed? I expected to see a MUST
there.

8) Is A.3 correct? If the selected method is breakable (if not why
bid down to it?) then the bad NAS can probably change the i1 message
so I'm not convinced by this argument.

nits:

- p10 - rfc5296bis is in IESG Evaluation, and obsoletes 5296 so you
should update the reference

- p11 - knowing that the client is using layer 2 crypto doesn't seem
very compelling if concerned about a bad NAS, since its the often the
case that the putative bad NAS that can see the plaintext, it could
leak that back over the air in clear if it wanted. (Liable to be
detected, but then so might lack of layer2 crypto in the client UI.)

- p22 - the NAS identifier can expose the user's location, depending
on how those are named and whether confid. is available for the
peer/server i1 or i2 message. That might be worth a mention.

[Ballot discuss]
I am escalating part of Barry's Comment to a Discuss

Please give the valid ranges for new code point registries.
Is the value zero reserved, out of scope, or unassigned?

[Ballot comment]
idnits reveals...

  -- The document has a disclaimer for pre-RFC5378 work, but was first
    submitted on or after 10 November 2008.  Does it really need the
    disclaimer?

I would prefer you to fix this (if it needs fixing) with a respin so
there is a copy of the document on file with the correct disclaimer.

---

Please expand acronyms on first use if they don't appear in
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt with an
asterisk.

I found...                                   

NAS (In the Abstract and a bit too late in the Introduction)
SSID (seciton 1)

---

Section 3

  o  Enterprise Network: A corporate network may have multiple virtual
      Lads (VLANs) running throughout their campus network

This is the most beautiful text I have read for a long time. Thank you!

BTW s/Lads/LANs/ is only part of the problem.
Does a LAN run through a network?

[Ballot comment]
-- IANA Considerations --

The definitions for the two new EAP Channel Binding Parameters sub-registries specify numbers in column one of the tables, but do not specify a range for those numbers.  Is it 0-255 (one byte)?  Something else?  Please specify, so IANA (and the rest of us) knows.  Similarly for the new sub-registry in 11.1.

I would like to see a brief rationale for the choices of Standards Action and IETF Review for the registration policies for the two new parameters sub-registries.  See draft-leiba-iana-policy-update if you want to see where I'm coming from on this.  Just something brief that shows that it was considered and discussed, and that explains why these were chosen.  Note: the definition for the new registry in 11.1 does give a rationale; thanks.

[Ballot comment]

  The Gen-ART Review by Francis Dupont on 7-Apr-2012 raised quite a few
  editorial comments.  The authors have indicated that many of them are
  very useful, and they want to update the document to address them, but
  this has not happened as yet.

IESG:

IANA has reviewed draft-ietf-emu-chbind-14.txt and has the following
comments:

IANA understands that, upon approval of this document, there are five IANA
actions which need to be compelted.

First, a new top-level registry will be created at:

http://www.iana.org/protocols/

This registry will be called the "EAP Channel Binding Parameters" registry and
will have a reference of [ RFC-to-be ].  This new registry will consist of
several new sub-registries.

Second, in the new EAP Channel Binding Parameters registry created above, a new
subregistry will be created called "Channel Binding Codes"

This subregisty will require standards action, as defined in RFC 5226 for
maintenance.  Early allocations to the registry are to be allowed.  There are
initial registrations for this new sub-registry as follows:

Code    Meaning                          Reference
------+----------------------------------+----------------
1      Channel Binding data from client  [ RFC-to-be ]
2      Channel binding response: success [ RFC-to-be ]
3      Channel binding response: failure [ RFC-to-be ]

Third, in the new EAP Channel Binding Parameters registry created above, a new
subregistry will be created called "Channel Binding Namespaces"

This subregisty will require standards action, as defined in RFC 5226 for
maintenance.  There are initial registrations for this new sub-registry as
follows:

ID      Namespace          Reference
--------+-----------------+---------------------
1      RADIUS            [ RFC-to-be ]
255    PRIVATE USE      [ RFC-to-be ]

Fourth, also in the new EAP Channel Binding Parameters registry created above, a
new subregistry will be created called "EAP Lower Layers Registry"

Maintenance of this registry will be done through Expert Review as defined in
RFC 5226.  There are initial registrations for this registry as followsL

+-------+----------------------------------------+---------------+
| Value | Lower Layer                            | Reference    |
+-------+----------------------------------------+---------------+
| 1    | Wired IEEE 802.1X                      | [ RFC-to-be ] |
| 2    | IEEE 802.11 (no-pre-auth)              | [ RFC-to-be ] |
| 3    | IEEE 802.11 (pre-authentication)      | [ RFC-to-be ] |
| 4    | IEEE 802.16e                          | [ RFC-to-be ] |
| 5    | IKEv2                                  | [ RFC-to-be ] |
| 6    | PPP                                    | [ RFC-to-be ] |
| 7    | PANA (no pre-authentication)          | [RFC5191]    |
| 8    | GSS-API                                | [I-D.ietf-abfab-gss-eap] 
    |
| 9    | PANA (pre-authentication) [RFC5873]    | [RFC6873]    |
+-------+----------------------------------------+---------------+

Fifth, a new RADIUS attribute will be registered in the RADIUS attribute type
subregistry of the Radius Types registry located at:

http://www.iana.org/assignments/radius-types/radius-types.xml

The new RADIUS attribute type will be registered as follows:

value: [ TBD at time of registration ]
Description: EAP-Lower-Layer
Reference: [ RFC-to-be ]


IANA understands that these five actions are the only actions required upon
approval of this document.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (Channel Binding Support for EAP Methods) to Proposed Standard





The IESG has received a request from the EAP Method Update WG (emu) to

consider the following document:

- 'Channel Binding Support for EAP Methods'

  as a Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-04-12. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  This document defines how to implement channel bindings for

  Extensible Authentication Protocol (EAP) methods to address the lying

  NAS as well as the lying provider problem.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-emu-chbind/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-emu-chbind/ballot/





No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Joe Salowey, EMU working group co-chair, is the Working Group Shepherd for this document. The shepherd has reviewed the current version and believes it is ready for publication.



(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had review from both key Working Group and Non-working group members. This includes members of the ABFAB community which relies upon this document.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

The document shepherd does not have concerns with the document and believes the document is needed. There has been no IPR disclosure related to the document.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?


The document has strong consensus within the working group. However, there is an individual who is not happy with the document, but has not posted comments on the latest revisions to the list. The working group and chairs feel it is appropriate to send the document to the IESG so additional comments can be made in IETF Last Call.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No one has threatened an appeal. See previous section.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the
Internet-Drafts Checklist

and
http://tools.ietf.org/tools/idnits/
). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The document passes ID-nits. There are a few reference issues that can be resolved in the editing process.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are complete.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section is complete.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This document defines how to implement channel bindings for
Extensible Authentication Protocol (EAP) methods to address the lying
NAS as well as the lying provider problem.



Working Group Summary
This document has had extensive review in the EMU working group.
The document has clear applicability in ABFAB and Network Access use cases.

Document Quality
Project Moonshot, an ABFAB implementation, is working on an implementation of this document.