Re: [secdir] secdir review of draft-ietf-emu-chbind-14
Hi Steve, Thanks for taking time to perform a detailed review the document. Comments inline below: On Apr 13, 2012, at 11:26 AM, Stephen Hanna wrote: > 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. > [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. > 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. > [Joe] OK > 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. > 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. > 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? [Joe] THis is historical and reflect
Re: [secdir] secdir review of draft-ietf-emu-chbind-14
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.
RE: [secdir] secdir review of draft-ietf-emu-chbind-14
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:hartmans-i...@mit.edu] > Sent: Monday, April 23, 2012 8:56 PM > To: Joe Salowey > Cc: Stephen Hanna; draft-ietf-emu-chb...@tools.ietf.org; > sec...@ietf.org; IETF-Discussion list; Sam Hartman > Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-14 > Importance: High > > > 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.
RE: [secdir] secdir review of draft-ietf-emu-chbind-14
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:
>
> On Apr 13, 2012, at 11:26 AM, Stephen Hanna wrote:
>
> > 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.
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?
> > 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.
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.
> > 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?
>
> [Joe] THis is historical and reflects the discussion we had in the
> working as the document was being developed.
>
> > 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 impleme
Re: [secdir] secdir review of draft-ietf-emu-chbind-14
On Apr 24, 2012, at 2:05 PM, Stephen Hanna wrote:
> 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:
>>
>> On Apr 13, 2012, at 11:26 AM, Stephen Hanna wrote:
>>
>>> 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.
>
> 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] In many cases the server credentials will be the same. They will be the
credentials of the AAA server.
>>> 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.
>
> 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] 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] THis is historical and reflects the discussion we had in the
>> working as the document was being developed.
>>
>>> 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
>>> 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 s
RE: [secdir] secdir review of draft-ietf-emu-chbind-14
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 > -Original Message- > From: Joe Salowey [mailto:jsalo...@cisco.com] > Sent: Wednesday, April 25, 2012 1:34 AM > To: Stephen Hanna > Cc: draft-ietf-emu-chb...@tools.ietf.org; sec...@ietf.org; IETF- > Discussion list; Sam Hartman > Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-14 > Importance: High > > > On Apr 24, 2012, at 2:05 PM, Stephen Hanna wrote: > > > 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: > >> > >> On Apr 13, 2012, at 11:26 AM, Stephen Hanna wrote: > >> > >>> 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. > > > > 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] In many cases the server credentials will be the same. They will > be the credentials of the AAA server. > > >>> 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. > > > > 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 ve
Re: [secdir] secdir review of draft-ietf-emu-chbind-14
> "Joe" == Joe Salowey 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. The
