Re: [secdir] secdir review of draft-ietf-emu-chbind-14

Stephen Hanna <shanna@juniper.net> Wed, 25 April 2012 14:20 UTC

Return-Path: <shanna@juniper.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA4621F85CE; Wed, 25 Apr 2012 07:20:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOaNe6GGnFmu; Wed, 25 Apr 2012 07:20:52 -0700 (PDT)
Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 199F921F855F; Wed, 25 Apr 2012 07:20:51 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT5gIKovjWSqQ+oT6bm+NBhQFKhtv5c2L@postini.com; Wed, 25 Apr 2012 07:20:51 PDT
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 25 Apr 2012 07:19:18 -0700
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Apr 2012 07:19:17 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 25 Apr 2012 10:19:17 -0400
From: Stephen Hanna <shanna@juniper.net>
To: Joe Salowey <jsalowey@cisco.com>
Date: Wed, 25 Apr 2012 10:19:16 -0400
Thread-Topic: [secdir] secdir review of draft-ietf-emu-chbind-14
Thread-Index: Ac0ipSXRiClaowWfTXGXyVxa8+AmcgAOvi8Q
Message-ID: <AC6674AB7BC78549BB231821ABF7A9AEB82EB26940@EMBX01-WF.jnpr.net>
References: <AC6674AB7BC78549BB231821ABF7A9AEB82E64DB6F@EMBX01-WF.jnpr.net> <FCD56997-4431-4BD2-9352-AABAB5DBD999@cisco.com> <AC6674AB7BC78549BB231821ABF7A9AEB82EB264BF@EMBX01-WF.jnpr.net> <4BB606A5-B3E0-4132-96EC-3E8BCE0B927B@cisco.com>
In-Reply-To: <4BB606A5-B3E0-4132-96EC-3E8BCE0B927B@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Sam Hartman <hartmans-ietf@mit.edu>, "draft-ietf-emu-chbind@tools.ietf.org" <draft-ietf-emu-chbind@tools.ietf.org>, IETF-Discussion list <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 14:20:53 -0000

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:jsalowey@cisco.com]
> Sent: Wednesday, April 25, 2012 1:34 AM
> To: Stephen Hanna
> Cc: draft-ietf-emu-chbind@tools.ietf.org; secdir@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 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 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.
> >>
> >> [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] I'm OK with this.
>
> >>> 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.
> >>
> >> [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] I agree we should work on a spec for 802.11 and perhaps other 802
> networks as well.
>
>
>
> >>> 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'd be inclined to warn about the problem since there may still
> > be some utility in checking the value. Whichever you prefer.
> >
>
> [Joe]   I think adding the warning is fine.
>
> >
> >>> 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] 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.
> >> "
> >
> > 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.
> >
> [Joe] Yes, thanks.
>
> >
> >>> 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:
> >>
> >> "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] 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.
>
> >>> 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:
> >>
> >> "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).
> >
> [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.