The EMU meeting is currently scheduled for Wednesday, November 10, 1510-1610. I would like to focus most of this time on EAP channel bindings. Please let me know if you have agenda items for the meeting. Priority will be given to items relevant towards progressing the channel bindings document. Cheers, Joe
_______________________________________________ Emu mailing list Emu <at> ietf.org https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu <at> ietf.org https://www.ietf.org/mailman/listinfo/emu
(1.a) Who is the Document Shepherd for this document?
==> Alan DeKok.
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?
==> Yes, and yes.
(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?
==> Yes
Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?
==> No.
(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?
==> It may be useful to have a review from someone in the security
community who has not been involved in the document development.
(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?
==> No.
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?
==> No.
If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.
(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 consensus shows strong consensus from a number of individuals.
The WG as a whole understands and agrees with the document.
(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?
==> No one has threatened an appeal.
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.)
(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?
==> Yes. The ID Nits are:
1) uses RFC 2119 text without RFC 2119 template. This is
intentional, and explained in the document
2) Using non-RFC3330 compliant IP addresses. This appears
to be a "false positive", as the document does not use
example IP addresses.
There are no other reviews necessary.
(1.h) Has the document split its references into normative and
informative?
==> Yes.
Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?
==> Yes. The document depends on draft-ietf-emu-chbind.
If such normative references exist, what is the
strategy for their completion?
==> The channel bindings document is expected to to be published
before any tunnel method document.
As a result, there appears to be no issue with publishing the
tunnel requirements document now.
Are there normative references
that are downward references, as described in [RFC3967]?
==> No.
If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].
(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?
==> Yes. There are no IANA considerations.
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?
(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?
==> This is 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 memo defines the requirements for a tunnel-based Extensible
Authentication Protocol (EAP) Method. This method will use Transport
Layer Security (TLS) to establish a secure tunnel. The tunnel will
provide support for password authentication, EAP authentication and
the transport of additional data for other purposes.
Working Group Summary
The document has had substantial review from a number of working
group participants. The working group is ready to start working on
protocols.
Document Quality
The document is a requirements document that has had contributions
from Working group participants from different vendors. Discussion
in the Working group has resulted in improvements to the document.
The IESG has received a request from the EAP Method Update WG (emu) to consider the following document: - 'Requirements for a Tunnel Based EAP Method' <draft-ietf-emu-eaptunnel-req-08.txt> as an Informational RFC 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 <at> ietf.org mailing lists by 2010-11-10. Exceptionally, comments may be sent to iesg <at> ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-emu-eaptunnel-req/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-emu-eaptunnel-req/ No IPR declarations were found that appear related to this I-D.
>>>>> "Joe" == Joe Salowey <jsalowey <at> cisco.com> writes:
As I discussed with the chairs, I'm making an update, but it's more of
an update to address specific detailed comments than to really move the
document forward. There have been some issues in my availability, which
I believe are very close to being resolved. This work is a dependency
for draft-ietf-abfab-gss-eap, which is one of my major projects so I
definitely do have the interest to move it forward. I'm sorry that did
not happen as much as we'd all like this cycle.
Joe> - Protocol definition - there is general consensus that we
Joe> should include the protocol definition within this document. I
Joe> think it would be good to flesh out the following approach in
Joe> the document to see if it meets working group expectations:
Joe> define a Channel-Binding-TLV to hold channel binding data;
Joe> define channel binding data as diameter AVPs. The protocol
Joe> should define attributes for at least one case (probably
Joe> 802.11) and provide guidance for creating binds for other
Joe> EAP/AAA usages in other follow-on documents.
Agreed.
Very little happened here.
Joe> Detailed comments follow:
Joe> 1. Introduction
Joe> I think it would be good discuss that the problem is manifested
Joe> when the same set of credentials are used to access different
Joe> classes or types of services. This is discussed later in
Joe> section 4.3, but I believe this to be fundamental to channel
Joe> binding problem and should be discussed in the introduction.
Joe> When the EAP server is centralized and accessed from different
Joe> for different services it typically uses the same set of
Joe> credentials to authenticate itself to the peer for each service
Joe> so the peer cannot differentiate between services. The server
Joe> could also attempt to detect any discrepancy by forcing the
Joe> client to use different credentials for each services. Using
Joe> different credentials for each different class or type of
Joe> service has numerous problems.
I added a brief mention in the introduction.
Let me know if more is needed.
Joe> 2. Section 3
Joe> In the Enterprise network case its not clear to me that channel
Joe> bindings alone can alleviate this attack. The peer does not
Joe> know which VLAN its traffic is going to, it just knows the
Joe> SSID. Likewise the AAA server does not know what VLAN the
Joe> authenticator is switching the peers traffic to, it only knows
Joe> what it told the authenticator to do, if the authenticator is
Joe> compromised, it need not comply. It is possible that this may
Joe> be detected by another part of the infrastructure, but this
Joe> would involve more than the authenticator, peer and AAA.
The unstated assumption here is that the authenticator was only trusted
to attach to one of the networks.
I.E. separate physical infrastructure for enforcing separate security
policy.
That's been stated.
It does diminish the applicability of the use case.
I also added the abfab use case; since that's been chartered it's
reasonable to mention here.
Joe> One mechanism that deployment use to avoid the "enterprise and
Joe> provider" problem today is to use different credentials for
Joe> remote access versus enterprise access. This is often not
Joe> ideal, but it addresses the problem.
mentioned.
Joe> 3. Section 4
Joe> It could be possible to use EAP channel bindings to address
Joe> some more traditional channel bindings uses cases by carrying
Joe> information from the lower layer or encapsulating tunnel in the
Joe> transported method.
Mentioned.
I dread writing or reading "The use of EAP Channel Bindings to Provide
RFC 5056 Channel Binding for EAP"
(draft-something-eap-chbind-for-chbind-for-eap)
I think it's an illustrative example of the difference, but at this time
I definitely don't want to get into whether it's a good idea.
For your information, I considered and rejected using EAP channel
binding for RFC 2743 channel binding (GSS) in
draft-ietf-abfab-gss-eap. Using the MSK and an exchange between the peer
and authenticator was simpler and didn't depend on the server verifying
I1 against I2 for that particular attribute. ABFAB still depends on EAP
channel binding in a number of other respects though.
Joe> 4. Section 4.2
Joe> This section states that for the system to function the EAP
Joe> server has to have access to a local database. THis doesn't
Joe> sound right to me. I wouldn't expect many systems would be
Joe> designed this way. The accuracy of the AAA attributes would be
Joe> verified by the AAA server that hosts the EAP server, but
Joe> perhaps this is too fine a distinction for this document. I
Joe> would expect any processing of AAA attributes to be done in the
Joe> AAA server.
I have added text to loosen the architecture in this regard.
However, it is very messy if your AAA server and EAP server are
decoupled and you want to make the decision in the AAA server.
Somehow the EAP server needs to communicate the set of attributes
supplied in I1 to the AAA server before generating the success
indication.
Then, the AAA server needs to make a decision and communicate that
decision along with what attributes from I1 were used to the EAP server.
The EAP server needs to encapsulate that in EAP and then eventually
return the decision.
ABFAB participants who have discussed the issue would like to depend on being able to get a list of
attributes that were actually considered. I think our reasons are
fairly general: without that it's easy for you to run into situations
where you fail insecure. We think that will apply to other
situations. Where you want to have a security policy on a peer that
actually involves the channel binding being checked, you need to depend
on this indication.
I think that for decoupled EAP and AAA servers the best you can do is as
follows.
The AAA server has the database. It verifies I2 against the database.
The AAA server passes along to the EAP server information on what its
requirements are for I1. That way the EAP server can verify I1 and
indicate what attributes are used. The "requirements" on I1 may be as
simple as a set of attributes that if present in I1 must match one of
several possible values enumerated by the AAA server.
For some applications it may be sufficient to give a list of attributes
that if present MUST match the values found in the AAA message.
Joe> 5. Section 4.3
Joe> I don't think the RSNIE containing security parameters is not
Joe> currently carried in a AAA attribute. Do we still want to use
Joe> this as an example?
I don't care much.
I left it in until someone provides an example they like more.
I don't think anything in this section is actually wrong.
Joe> I'm not sure what the 3rd paragraph is getting at. The peer
Joe> usually does not have any clue as to what specific VLANs are in
Joe> use, so its not clear to me what this is saying.
I tried to clean this up.
Joe> This section probably should briefly cover that in some cases
Joe> it is possible that the EAP-Server is collocated with the
Joe> authenticator and AAA is not involved.
I did touch on that in the document; I don't think it ended up here.
Joe> 6. Section 5.1
Joe> In this section I have the same comment about the EAP Server
Joe> accessing the database. I think the EAP server interfaces with
Joe> AAA and AAA maintains and process the AAA
Joe> attributes. Conceptually the result is the same, so maybe its
Joe> not such a big deal. Maybe it would be helpful to describe
Joe> that other architectural choices are valid. Separating out the
Joe> i2 consistency check form the i1 validation could allow the
Joe> consistency of some attributes to be checked on a different AAA
Joe> server.
I talked about some parts of I2 being checked on a different AAA server.
Joe> 7. Section 7
I have no strong opinions about section 7 and 8. I think I'm going to
need help/text on these sections from someone who has strong opinions.
--Sam
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : Channel Binding Support for EAP Methods Author(s) : S. Hartman, et al. Filename : draft-ietf-emu-chbind-06.txt Pages : 26 Date : 2010-10-25 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
_______________________________________________ Emu mailing list Emu <at> ietf.org https://www.ietf.org/mailman/listinfo/emu
IETF-79 - EMU Working Group WEDNESDAY, November 10, 2010, 1510-1610 Afternoon Session II Garden Ballroom 1 ======================================== 1. Administrivia (note takers, blue sheets, agenda) - 5min 2. EAP Channel Bindings - Sam Hartman - 35min http://tools.ietf.org/html/draft-ietf-emu-chbind-06 3. EAP-TEAM - Glen Zorn - 10Min http://tools.ietf.org/html/draft-zorn-emu-team-01
RSS Feed8 | |
|---|---|
3 | |
16 | |
14 | |
2 | |
4 | |
31 | |
11 | |
16 | |
13 | |
20 | |
12 | |
39 | |
18 | |
26 | |
3 | |
6 | |
50 | |
5 | |
30 | |
7 | |
5 | |
44 | |
30 | |
13 | |
10 | |
6 | |
9 | |
4 | |
8 | |
18 | |
5 | |
9 | |
57 | |
9 | |
5 | |
100 | |
2 | |
3 | |
34 | |
4 | |
9 | |
31 | |
106 | |
17 | |
11 | |
12 | |
3 | |
15 | |
74 | |
22 | |
18 | |
16 | |
28 | |
31 | |
35 | |
23 | |
35 | |
9 | |
35 | |
16 | |
30 | |
30 | |
13 | |
8 | |
30 | |
17 | |
53 | |
12 | |
53 | |
12 | |
80 | |
53 | |
56 | |
23 | |
16 | |
80 | |
60 | |
38 | |
23 | |
46 | |
1 | |
4 | |
7 | |
2 |
