>>>>> "Joe" == Joe Salowey <jsalowey@xxxxxxxxx> writes:
Hi.
I'm responding where I'm not able to just take Steve's changes.
Joe> Hi Steve, Thanks for taking time to perform a detailed review
>> 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.
>>
[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.
There are a couple of things going on.
first, not all EAP methods distinguish server and client credentials.
Generally, you can fix the problem either way: use different server
credentials or have access to disjoint service sets from different
client credentials.
Lots of factors affect whether that's an adequate defense. For example
using different server credentials for accessing different services
provides no defense for peers who do not validate server credentials.
I've added a sentence indicating that generally either type of
credential can be used as a defense but I have not gone into the full
details.
That's not appropriate for the introduction and may not be appropriate
for this document.
>> 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.
>>
[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.
I think Steve's clarification makes the text worse.
Conceptually/trust wise, the peer and EAP server are very close. There's
a protected path between them.
I've added
both in terms of network distance and number of entities who need to be
trusted in order to establish trusted communication
I'm also happy with the original text.
>> 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.
>>
[Joe] I agree having a more concrete example would be helpful.
The reason I didn't do that is that trust is relative.
Apparently in Steve's environments mail servers are more trusted than IM
servers. In my environments I think the opposite may be true, although
both are relatively untrusted.
I added "For example, the instant messaging service could impersonate
the mail server."
I think there is a WG consensus to keep that text, and would push back
against a change at this point.
I'm fairly sure this issue was discussed in the WG and keeping that
text was part of a compromise to move forward with a specific approach.
Like Joe, if there are clarity issues surrounding what's normative I'd
like to make sure those are fixed.
>> 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.
>>
[Joe] OK
I added (i2 below) to the sentence.
There's a fair bit of detail around this information in the following
text.
>> 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.
>>
[Joe] OK
Thanks for this catch!
>> 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.
>>
[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 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?
>>
[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:
Joe> "sending the result from server to peer over
Joe> integrity-protected channel"
Good tactch; made a similar change.
>> 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".
Joe> [Joe] As EAP is deployed in most cases today the authenticator
Joe> is not identified, it is merely authorized as being part of the
Joe> network. The peer does not expect differentiated service based
Joe> on the NAS it is connected to. Since the service is the same
Joe> it does not matter to the peer if one authenticator
Joe> impersonates another. When we start discussing use case such
Joe> as ABFAB where different services are being provided did the
Joe> identity of the authenticator really become an issue.
Joe> Perhaps the following text is better
Joe> "In many EAP deployments today attacks where one authenticator
Joe> can impersonate another not a real concern since different
Joe> authenticators provide the same service. In these situations
Joe> an authenticator does not gain significant advantage in
Joe> impersonating another authenticator. "
>> 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.
>>
[Joe] I see your point here, how about:
Joe> "The use of EAP in situations where different authenticators
Joe> provide different services makes the ability to authorize
Joe> different authenticators more important. The system as a whole
Joe> needs to be analyzed to evaluate cases where one authenticator
Joe> may impersonate another and to evaluate the impact of this
Joe> impersonation. Channel bindings provides a way to address
Joe> these issues. "
>> 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.
>>
[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:
Joe> "Even when cryptographic binding does attempt to confirm that
Joe> the inner and outer server are the same, the Master Session Key
Joe> (MSK) from the inner method is typically used to protect the
Joe> binding. However, if the outer method tunnel terminates on the
Joe> authenticator the inner MSK is disclosed to the authenticator,
Joe> which can attack cryptographic binding."
>> 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.
>>
[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:
Joe> "If the authenticator controls the cryptographic binding then
Joe> it also controls the channel binding parameters and results.
Joe> If the channel binding process is used to differentiate one
Joe> authenticator from another then the authenticator can claim to
Joe> support services that it was not authorized to. This attack
Joe> was not in scope for existing threat models for cryptographic
Joe> binding because differentiated authenticators was not a
Joe> consideration. Thus, existing cryptographic binding does not
Joe> typically provide mutual authentication of the inner method
Joe> server required for channel binding."
>> 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.
>>
[Joe] I think you are correct.
>> 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.
>>
[Joe] I think this is a valid concern for some environments. I think we should add a section for that.
>> 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?
>>
[Joe] The result message is not intended to be optional. This text needs to be fixed.
>> 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.
Joe> [Joe] Yes
>> 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.
>>
[Joe] OK, I need to check if there is any convention here.
>> 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.
>>
[Joe] OK
>> 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.
>>
[Joe] Yup, left over from previous version.
>> Appendix A is pretty similar to section 1. Might you 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.
>> 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.
>>
[Joe] I believe you are correct.