Subject: secdir review of draft-ietf-emu-chbind-14

From: Stephen Hanna <[email-masked]>
Date: Fri, 13 Apr 2012 14:26:43 -0400

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG. These comments were written primarily for the benefit of the 
security area directors. Document editors and WG chairs should treat 
these comments just like any other last call comments. I apologize
for submitting these comments a day after the IETF LC closed.
Other commitments delayed my work. I hope these are still useful.

Thanks,

Steve

------

secdir review of draft-ietf-emu-chbind-14

This document defines channel bindings for EAP methods, providing
a way to address the lying NAS and lying provider problems.

Overall, I have no objections to this document. However,
I do have some comments. I have divided these comments
into substantive and non-substantive ones.

Substantive Comments
--------------------

In the Introduction, the second paragraph says that the
problem "results when the same credentials are used to
access multiple services that differ in some interesting
property". Do you mean client or server credentials?
I think you mean EAP server credentials. Please be more 
explicit to make this clearer, since many people will
assume that you mean client (EAP peer) credentials. If
I'm correct and you do mean EAP server credentials,
I suggest that you say so in the first sentence of
this paragraph and also in the last sentence.

In the next paragraph, you give an example where a low
security network is used to read email and a high security
network is use to access valuable confidential information.
A better example would be to use the low security network
for web surfing. Reading email can require a lot of security.

In the first paragraph of the Problem Statement, the second
sentence says "However, when operating in pass-through mode,
the EAP server can be far removed from the authenticator."
While this is true, I think the more relevant statement here
is that the EAP server can be far removed from the EAP peer.
This paragraph is all about problems that can arise when
parties between the EAP peer and the EAP server (including
the authenticator) are malicious or compromised. So the
important thing to point out at the start of the paragraph
is the large number of parties that may come between the
EAP server and the EAP peer.

In the second bullet of section 3 (on page 7), the EAP GSS-API
mechanism is a good example. However, I wonder if this attack
might take a slightly different form. Could the IM server
pretend to be the mail server? I think so. That's just one
specific example of a relatively untrusted service pretending
to be a relatively trusted service. I suggest that you add
an example like that since the current language is quite
abstract.

Overall, I found the document too abstract for my taste. When
I read an RFC that's defining a protocol to be implemented,
I prefer to read a description of the problem to be solved
and then a clear definition of the protocol. This document
reads like a combination of an academic paper and a protocol
definition. For example, section 4.1 describes two categories
of approach to EAP channel bindings: exchanging the actual
network information or encoding the network information into
a blob that is used to derive EAP session keys. The rest of
section 4.1 goes on to discuss the pros and cons of these
approaches. Then section 4.2 defines a bunch of requirements
for transporting channel bindings in a lower layer's secure
association protocol. While that's interesting, the actual
protocol defined in this document sends the actual network
information in EAP. Why bother spending several pages talking
about things that this protocol doesn't actually do? I see
several downsides to including that text in this document.
First, you're making it harder for the reader to understand
what they actually need to do to implement this protocol.
You've probably decreased by half the number of people who
will actually read all of this document. Second, some people
will use that digression to support arguments like ("My
incompatible implementation is compliant with RFC XXXX
because I encoded the network information into a blob
and used that to generate EAP session keys"). IETF is an
engineering organization. We should make our specs as clear
and simple as possible and no simpler. This document includes
lots of interesting theory that's not needed for its purpose.
If you're interested in seeing this document widely implemented,
I suggest that you remove as much of that as possible and focus
the document on explaining the problem and defining a protocol
that solves it. Or you can leave it as is. I'm sure some people
will implement it. Just not as many. Friendly suggestion. Take
it or leave it.

In the first paragraph of section 5.1, you say that "the
EAP server needs to be able to access information from the
AAA server that is utilized during the EAP session and a
local database". Which information? A parenthetical example
(an e.g.) would help with understanding what you mean.

In section 7.1, you explain that this document isn't useful
without an accompanying document defining what information
should be included in i1 for each lower layer. Are those
documents being prepared for all or at least some of the
lower layers? I couldn't find any in a quick search. I know
we can't wait for everything to be ready but it would be
nice to see at least one or two of those documents so that
we can have confidence that this protocol can support all
the things that those documents will need.

In section 7.2, you define a new RADIUS attribute that
identifies the EAP lower layer in use. But you say in
the first sentence of that section that this attribute
is defined to "carry the EAP lower layer". That sounds
like all the lower layer traffic will be encapsulated
in this attribute and carried in it. I think you should
change the word "carry" in that text to "identify".
Unless I misunderstood you.

As I read section 8, I wonder whether include the User-Name
attribute in i2 could open the system up to attacks where
an authenticator or intermediate proxy could remove the
anonymity of a user who's using a pseudonym for the
username by changing the value of the User-Name attribute
to the username of the user suspected of being responsible
for this authentication. If the channel bindings checks
fail, the authenticator will know they were wrong but if
the channel bindings checks succeed, the authenticator
will have confirmation of the user's identity.

I didn't understand that sending i2 from the server to
the peer is optional until I got to section 9.1. In section
5.3, you said that "For success, the server returns the
attributes that were considered by the server in making
the determination that channel bindings are successfully
validated". Which of these is right?

At the top of page 23, you say that "In many EAP deployments
today attacks where one NAS can impersonate another are
out of scope." Do you mean that these attacks are generally
not considered but they are a potential problem? Or that
they are not a problem? I think they are always a possible
problem. Even when all the NASes are owned and managed by
the same organization that runs the AAA server and no proxies
are used, there's still the potential for a NAS to become
compromised. So I think you should say these attacks are
"not considered although a real concern" not that they are
"out of scope". And then the following sentence says that
"Channel bindings brings these attacks into scope". Again,
I think those attacks are always a potential issue. Channel
bindings provide a good way to address them, whereas there
were few ways to do so before. Maybe it would be better to
say that.

In the next paragraph, you say that when cryptographic binding
is used in a tunnel method, the MSK is disclosed to the NAS.
I don't think that's right. The MSK that's disclosed to the
NAS is the one generated by the outer method. The MSK that's
used in cryptographic binding is the one that's generated by
the inner method. I don't think there's a problem there.

Later in that paragraph, you say that an attack where the NAS
terminates an EAP tunnel method is not in scope for existing
models for cryptographic binding. I think that's wrong also.
EAP tunnel methods protect against just this sort of attack.
The first step in these methods is for the EAP peer and the
EAP server to build a TLS tunnel. This requires the EAP peer
to authenticate the EAP server and decide whether it's trusted.
If the NAS has credentials that will cause the EAP peer to
trust it as an EAP server, a MITM attack is possible. Of course,
that's true for any secure communications and it's a very bad
situation. That's why the EAP peer must be very careful about
who it trusts and how it authenticates them and the EAP server
(and any CAs or other TTPs) must also be similarly careful.
I don't see that any of this has much to do with channel bindings.
Am I missing something here? If so, please explain it. And maybe
you can clarify the text so that other folks get it also.

In section 9.2, this paragraph appears:

   Dishonest peers can only manipulate the first message i1 of the
   channel binding protocol.  In this scenario, a peer sends i1' to the
   server.  If i1' is invalid, the channel binding validation will fail.
   On the other hand if i1' passes the validation, either the original
   i1 was wrong and i1' corrected the problem or both i1 and i1'
   constitute valid information.  A peer could potentially gain an
   advantage in auditing or charging if both are valid and information
   from i1 is used for auditing or charging.  Such peers can be detected
   by including the information in i2 and checking i1 against i2.

In the penultimate sentence, I think you mean "information from
i1' is used for auditing or charging." There's no problem if
information from i1 is used for auditing. If that happens, the
bad peer's information is being ignored.

That paragraph does make me wonder about another attack that
could be enabled by channel bindings. What if a malicious peer
gets perfectly good i1 from a NAS but then sends bad i1' to
the EAP server with a goal of damaging the reputation of the
NAS? The EAP peer could be working for a competitor of the
organization that runs the NAS or just be malicious. Is that
a valid concern? If so, maybe you should cite it and suggest
a countermeasure.

In section 9.4, you refer to "the optional result message".
I didn't know before this that the result message was optional.
Could you make that clear earlier?

In the IANA Considerations, you talk about creating a new
"EAP Channel Binding Parameters" top level registry. That's
fine. But then you talk about a "Channel Binding Codes"
registry. Didn't you mean a "sub registry"? If you want
the Channel Binding Codes registry to be in the EAP Channel
Binding Paramters registry, I think the first one is really
a sub registry. Also, you say that "Early allocation is
allowed" for that registry. What does that mean? I don't
see any description of "early allocation" in RFC 5226.
I expect that IANA will want to know what they need to
do to provide "early allocation". How early? Etc.

In the definition of the "Channel Binding Namespaces"
registry, did you want to include a reference column
as you did in the "Channel Binding Codes" registry?
If so, maybe you should say so.

At the end of section 11.1, a sentence says that
"Values skipped in the above table are available
for assignment." I don't think any values were skipped
so I don't think you need that sentence.

Appendix A is pretty similar to section 1. Might you
be able to merge them somehow?

In section A.3, you describe downgrading attacks and
how channel bindings can prevent them. However, I think
this will only work if the EAP peer rejects all methods
that don't include channel bindings. Otherwise, the NAS
can just offer an unauthorized EAP method that permits
it to obtain the user's credentials and off to the bank.

Non-Substantive Comments
------------------------

In the top right header of the first page, the organization
for T. Clancy should probably be Virginia Tech not Electrical
and Computer Engineering.

In the fourth paragraph of the Introduction, I think you should
add the word "the" before "lying provider" problem. In the last
sentence of that paragraph, I'd suggest adding "also" before
"gain access". That should make things clearer.

In the first bullet in section 3 (at the bottom of page 6),
"virtual Lads" should probably be "virtual LANs". Unless you
are talking about some other phenomenon! ;-)

In the second paragraph of section 4.3, the phrase "More often
it is useful" can be confusing. The word "it" seems to refer
to the subject of the previous sentence ("verification of the
MAC or IP address of the NAS"). Actually, the word "it" refers
to the idea of making policy decisions about services but that
idea doesn't appear until later in the sentence. I suggest that
you reword the sentence to say "More often the best approach is
to make policy decisions [...]".

In the first sentence of section 8, the phrase "a AAA Accept-
Request messages" can't be right. Is it singular or plural?
I think it's plural so the word "a" should be removed.

In section 12 (Acknowledgements), I think Sam Hartman's last
name should be capitalized.

---

From: Joe Salowey <[email-masked]>
Date: Mon, 23 Apr 2012 14:06:38 -0700

Hi Steve,

Thanks for taking time to perform a detailed review the document.  Comments  inline below:

> into substantive and non-substantive ones.

[Joe]   The case here is both client and server credentials.  If different credentials are required for each type of service then the authenticator will not be able to lie about the type of service it is representing to the client because the client credentials are bound to the service. 

> for web surfing. Reading email can require a lot of security.

[Joe] OK 

> EAP server and the EAP peer.

[Joe]  I think I see your point, but I'm not sure.  Traditionally, we have often thought of the path between EAP peer and EAP authenticator as being vulnerable to having multiple parties able to insert themselves into the conversation.  However it may be the case that the authenticator the peer is talking to isn't the one it thinks it is and the "real" authenticator may be somewhere in the path as well.  The conversation between the EAP peer and EAP server will not be compromised, however the result of the conversation may not have its intended effect.  

> an example like that since the current language is quite

[Joe] I agree having a more concrete example would be helpful.  

> about things that this protocol doesn't actually do?

[Joe] THis is historical and reflects the discussion we had in the working as the document was being developed. 

> I see

[Joe] I can see your point, but I think some members of the working group would object if we removed some of this material.  If its not clear perhaps we can so a better job of indicating what is normative and what is informative. 

> (an e.g.) would help with understanding what you mean.

[Joe] OK

> the things that those documents will need.

[Joe]  That not how I interpret the text in section 7.1. This document does specify a general attribute that can be used to specify the type of lower layer used to carry EAP.    Section 7.1 states that additional documents will be needed to specify attributes specific to a particular lower layer.   ABFAB is working on a document that contains this information for their lower layer, draft-ietf-abfab-gss-eap.

> Unless I misunderstood you.

[Joe] OK

> will have confirmation of the user's identity.

[Joe] Perhaps, on the one hand I would think the system would not behave this way, the server would be expecting a pseudonym or token and fail if it got something else.  On the other hand, I don' think the text for the user-name check or the test itself are that useful.  We could either warn against the possible identity disclosure or remove the user-name check.  

> validated". Which of these is right?

[Joe]  The server is required to return the channel-binding attributes it verified because the client may require certain attributes to be checked.   This list of verified attributes is not equivalent to i2.  i2 is what attributes are sent in the AAA protocol and I don't think it should be referenced here.  Instead it should probably say:

"sending the result from server to peer over integrity-protected channel"

> "out of scope".

[Joe] As EAP is deployed in most cases today the authenticator is not identified, it is merely authorized as being part of the network.  The peer does not expect differentiated service based on the NAS it is connected to.  Since the service is the same it does not matter to the peer if one authenticator impersonates another.  When we start discussing use case such as ABFAB where different services are being provided did the identity of the authenticator really become an issue.  

Perhaps the following text is better

"In many EAP deployments today attacks where one authenticator can impersonate another not a real concern since different authenticators provide the same service.  In these situations an authenticator does not gain significant advantage in impersonating another authenticator. "

> And then the following sentence says that

[Joe] I see your point here, how about:

"The use of EAP in situations where different authenticators provide different services makes the ability to authorize different authenticators more important.   The system as a whole needs to be analyzed to
   evaluate cases where one authenticator may impersonate another and to evaluate the impact of this impersonation.  Channel bindings provides a way to address these issues. "

> the inner method. I don't think there's a problem there.

[Joe]  OK, this test is referring to where there is separate between the terminating server of the inner and outer methods.  Maybe it would be clearer if the text said the following:

"Even when cryptographic binding does attempt to confirm that the inner and outer server are the same, the Master Session Key (MSK) from the inner method is typically used to protect the binding.  However, if the outer method tunnel terminates on the authenticator the inner MSK is disclosed to the authenticator, which can attack cryptographic binding." 

> you can clarify the text so that other folks get it also.

[Joe]  The issue is when you have different services the client may not have enough information to determine what an authenticator is authorized for based on its identity alone.  In this case it would like help from the server that terminates the inner method.  However current crypto binding is based on the MSK so the authenticator can generate whatever channel binding quantities it wants because the authenticator has all the necessary key material.  In order for channel bindings to determine if the authenticator is authorized or not,   the method needs protect the channel bindings with a key generated from the inner method EMSK that the authenticator does not possess.   Here is some text that may help:

"If the authenticator controls the cryptographic binding then it also controls the channel binding parameters and results.  If the channel binding process is used to differentiate one authenticator from another then the authenticator can claim to support services that it was not authorized to.  This attack was not in scope for existing threat models for cryptographic binding because differentiated authenticators was not a consideration.  Thus, existing cryptographic binding does not typically provide mutual authentication of the inner method server required for channel binding."

> bad peer's information is being ignored.

[Joe]  I think you are correct.

> a valid concern? If so, maybe you should cite it and suggest

[Joe] I think this is a valid concern for some environments.  I think we should add a section for that.  

> Could you make that clear earlier?

[Joe] The result message is not intended to be optional.  This text needs to be fixed. 

> a sub registry.

[Joe] Yes

> Also, you say that "Early allocation is

[Joe] OK, I need to check if there is any convention here. 

> If so, maybe you should say so.

[Joe] OK

> so I don't think you need that sentence.

[Joe] Yup, left over from previous version. 

> be able to merge them somehow?

[Joe] I think the authors attempted to do this and then decided it was better to keep them separate. 

> it to obtain the user's credentials and off to the bank.

[Joe] I believe you are correct. 

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Apr 2012 20:56:29 -0400

First, Steve, thanks for an excellent review.
You detected some really important fixes we need to make!

Hi.  I'll respond in more detail later.  I generally agree with Joe's
comments.
I want to respond to the IANA issues so Joe doesn't have to dig around.

Early allocation is a well-defined concept; I forgot to reference the
appropriate RFC, but IANA does (and according to their last call
comments did in this case) understand it.

IANA also correctly assumed the codes registry is a sub-registry not a
new top-level registry.

I don't mind fixing, but I'll point out that IANA was not actually
confused nor did they request clarification.

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 24 Apr 2012 08:27:50 -0400

Sam,

I'm glad that my review was helpful. That's just what I hoped.
I wanted to provide the perspective of a new reader, someone
who wasn't deeply involved in the development of the document.
After all, that's one of the main purposes of publishing an RFC:
to get this information out to a broader community, a bunch of
new readers.

And I'm happy to hear that all the IANA Considerations were
clear to the IANA team. I appreciate your plans to add a
reference to the RFC that defines "early allocation". That
will help ensure that the IANA Considerations are clear not
only to IANA but also to the more casual reader.

Joe's response to my review was very helpful also.
He answered many of my questions and concerns.
I'm working on a response to Joe's email now.
And I look forward to seeing your more detailed
response also.

Thanks,

Steve

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Monday, April 23, 2012 8:56 PM
> To: Joe Salowey
> Cc: Stephen Hanna; [email-masked];
> [email-masked]; IETF-Discussion list; Sam Hartman
> Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-14
> Importance: High
> 
>

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 24 Apr 2012 17:05:35 -0400

Joe,

I'm glad that my comments were useful to you and to the editors
of this draft. I will respond to your comments below inline.
I'm going to clip out as much as I can, including anything
that has already been agreed on.

Thanks,

Steve

----------

Joe Salowey wrote:
> [Joe]   The case here is both client and server credentials.  If
> different credentials are required for each type of service then the
> authenticator will not be able to lie about the type of service it is
> representing to the client because the client credentials are bound to
> the service.

SH> I don't see what the problem is with using the same
client credentials with two different services if the
server credentials are different. The client will be able
to detect a lying NAS easily since the server credentials
won't match what it expects for that service. Could you
please explain this more?

> [Joe]  I think I see your point, but I'm not sure.  Traditionally, we
> have often thought of the path between EAP peer and EAP authenticator
> as being vulnerable to having multiple parties able to insert
> themselves into the conversation.  However it may be the case that the
> authenticator the peer is talking to isn't the one it thinks it is and
> the "real" authenticator may be somewhere in the path as well.  The
> conversation between the EAP peer and EAP server will not be
> compromised, however the result of the conversation may not have its
> intended effect.

My point is that having a long distance between the EAP server
and the authenticator has little to do with the "lying NAS"
problem. The problem is that there are potentially untrustworthy
parties (the NAS and any proxies) between the EAP peer and the
EAP server and the EAP peer is trusting what it's told by them.
If the EAP server and the authenticator were two inches apart
with no intermediaries, that wouldn't help. The problem is the
potentially untrustworthy folks between the EAP server and
the EAP peer. You're trying to verify some of what they're
telling the EAP peer. So I'm not sure that sentence helps but
if it does, the problem is between the EAP peer and the EAP server.

> [Joe] THis is historical and reflects the discussion we had in the
> working as the document was being developed.
>
> > I see
> [Joe] I can see your point, but I think some members of the working
> group would object if we removed some of this material.  If its not
> clear perhaps we can so a better job of indicating what is normative
> and what is informative.

OK. If you think the WG really wants this confusing text,
leave it in. But maybe you should start section 4 by saying
"This section describes several possible design choices
for channel bindings. It is not normative." And then you'll
need to change, delete, or move the paragraph in section 4.2
that includes a MUST and a SHOULD. I think that paragraph is
redundant with the first paragraph in section 6.1 and not
specific to sending channel bindings in the Secure Association
Protocol (which is the topic of section 4.2) so I'd suggest
that you just delete it. You won't lose anything.

> [Joe]  That not how I interpret the text in section 7.1. This document
> does specify a general attribute that can be used to specify the type
> of lower layer used to carry EAP.    Section 7.1 states that additional
> documents will be needed to specify attributes specific to a particular
> lower layer.   ABFAB is working on a document that contains this
> information for their lower layer, draft-ietf-abfab-gss-eap.

Without a document that defines what information should be
included in i1 for a given lower layer, the only thing this
protocol gives you is a way to confirm that the EAP server
is OK with the lower layer advertised by the authenticator.
Whoop-dee-do. That doesn't address any of the use cases
described in the Problem Statement. In all those cases,
the authenticator is advertising a lower layer that's
supported by the EAP server.

I'm not saying that EAP channel bindings have no value.
I'm just saying that they don't have much value without
a document that specifies the attributes relevant to
the lower layer that's in use. So let's publish this
spec and the GSS-EAP spec. But let's also work on a
spec that describes the attributes for 802.11.

> [Joe] Perhaps, on the one hand I would think the system would not
> behave this way, the server would be expecting a pseudonym or token and
> fail if it got something else.  On the other hand, I don' think the
> text for the user-name check or the test itself are that useful.  We
> could either warn against the possible identity disclosure or remove
> the user-name check.

I'd be inclined to warn about the problem since there may still
be some utility in checking the value. Whichever you prefer.

> [Joe]  The server is required to return the channel-binding attributes
> it verified because the client may require certain attributes to be
> checked.   This list of verified attributes is not equivalent to i2.
> i2 is what attributes are sent in the AAA protocol and I don't think it
> should be referenced here.  Instead it should probably say:
>

OK, fine.

> [Joe] As EAP is deployed in most cases today the authenticator is not
> identified, it is merely authorized as being part of the network.  The
> peer does not expect differentiated service based on the NAS it is
> connected to.  Since the service is the same it does not matter to the
> peer if one authenticator impersonates another.  When we start
> discussing use case such as ABFAB where different services are being
> provided did the identity of the authenticator really become an issue.
>
> "In many EAP deployments today attacks where one authenticator can
> impersonate another not a real concern since different authenticators
> provide the same service.  In these situations an authenticator does
> not gain significant advantage in impersonating another authenticator.
> "

I'd say "all authenticators provide the same service". I think
that's what you meant to say. With that change, my concerns are
allayed.

> "The use of EAP in situations where different authenticators provide
> different services makes the ability to authorize different
> authenticators more important.   The system as a whole needs to be
> analyzed to
>    evaluate cases where one authenticator may impersonate another and
> to evaluate the impact of this impersonation.  Channel bindings
> provides a way to address these issues. "

Yes, good.

> [Joe]  OK, this test is referring to where there is separate between
> the terminating server of the inner and outer methods.  Maybe it would
> be clearer if the text said the following:
>
> "Even when cryptographic binding does attempt to confirm that the inner
> and outer server are the same, the Master Session Key (MSK) from the
> inner method is typically used to protect the binding.  However, if the
> outer method tunnel terminates on the authenticator the inner MSK is
> disclosed to the authenticator, which can attack cryptographic
> binding."

Who on earth would terminate the outer method on the authenticator?
The authenticator should be trusted as little as possible. The party
who terminates the outer tunnel method must be highly trusted.
One of the main benefits of having an authentication server is to
reduce the number of highly trusted parties by centralizing the
most security-critical activities such as authentication. That's
why we have pass-through authenticator mode. Maybe you're not
talking about using EAP pass-through authenticator mode any more.
In that case, there's no backend authentication server so this
whole document does not apply. At least, I don't think it does.
Could you point out to me where in this document it explains
how to handle this situation? If this situation is not in scope
for this document, I think you should say that and remove this
text about MSK problems since they don't apply to this document.
If not using pass-through authenticator mode is in scope for
this document, please say that and explain how EAP channel
bindings work in that environment.

> [Joe]  The issue is when you have different services the client may not
> have enough information to determine what an authenticator is
> authorized for based on its identity alone.  In this case it would like
> help from the server that terminates the inner method.  However current
> crypto binding is based on the MSK so the authenticator can generate
> whatever channel binding quantities it wants because the authenticator
> has all the necessary key material.  In order for channel bindings to
> determine if the authenticator is authorized or not,   the method needs
> protect the channel bindings with a key generated from the inner method
> EMSK that the authenticator does not possess.   Here is some text that
> may help:
>
> "If the authenticator controls the cryptographic binding then it also
> controls the channel binding parameters and results.  If the channel
> binding process is used to differentiate one authenticator from another
> then the authenticator can claim to support services that it was not
> authorized to.  This attack was not in scope for existing threat models
> for cryptographic binding because differentiated authenticators was not
> a consideration.  Thus, existing cryptographic binding does not
> typically provide mutual authentication of the inner method server
> required for channel binding."

Again, you've moved beyond pass-through authentication mode. I don't
think this document covers that. If it's meant to cover that, it's
missing a lot of text (to describe how that works).

> better to keep them separate.

OK.

---

From: Joe Salowey <[email-masked]>
Date: Tue, 24 Apr 2012 22:34:29 -0700

> that has already been agreed on.

[Joe] In many cases the server credentials will be the same.  They will be the credentials of the AAA server.  

> if it does, the problem is between the EAP peer and the EAP server.

[Joe] I don't have an issue with stating that the problem is between the peer and the server, but I'd like to hear the author's view on this. 

> that you just delete it. You won't lose anything.
[Joe] I'm OK with this. 

> spec that describes the attributes for 802.11.

[Joe] I agree we should work on a spec for 802.11 and perhaps other 802 networks as well.  

> be some utility in checking the value. Whichever you prefer.

[Joe]   I think adding the warning is fine.

> that's what you meant to say. With that change, my concerns are
[Joe] Yes, thanks.

> bindings work in that environment.

[Joe] So, I'm not a big fan of splitting the inner and outer methods, but there have been quite a few advocates for various use cases.  The current issue was brought up in ABFAB so I think Sam would be better at providing the motivation for that. 

> missing a lot of text (to describe how that works).
[Joe] True, that is why this was previously out of scope.  I think there are other places where a more detailed of the ABFAB use case would help.

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 25 Apr 2012 10:19:16 -0400

Thanks, Joe. Looks like we've reached agreement on most things.
There are a few items left where Sam's input is needed.
I'll wait to see what he has to say.

Thanks,

Steve

> From: Joe Salowey [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2012 1:34 AM
> To: Stephen Hanna
> Cc: [email-masked]; [email-masked]; IETF-
> Discussion list; Sam Hartman
> [Joe] I don't have an issue with stating that the problem is between
> the peer and the server, but I'd like to hear the author's view on
> this.
>
> >>
> [Joe] So, I'm not a big fan of splitting the inner and outer methods,
> but there have been quite a few advocates for various use cases.  The
> current issue was brought up in ABFAB so I think Sam would be better at
> providing the motivation for that.
>
> [Joe] True, that is why this was previously out of scope.  I think
> there are other places where a more detailed of the ABFAB use case
> would help.