Keith Welter <welt...@us.ibm.com> wrote on 10/07/2010 10:26:56 AM: [...] > Yoav Nir <y...@checkpoint.com> wrote on 10/07/2010 12:48:17 AM: > [...] > > Hi Keith. > > > > My responses are below, but first I would like to know if you have > > considered a different solution - having an IKE_AUTH exchange in the > > middle of the IKE SA lifetime. Suppose the IKE SA has been around > > for a couple of hours, and has been used for creating some child > > SAs, why not keep it and just pass one or more IKE_AUTH exchanges? > Interesting. If support for the new reauth protocol is signaled in > the original IKE_AUTH exchange then I think you could do a modified > IKE_AUTH exchange in the old IKE SA to accomplish reauthentication. > That would eliminate moving the children and having to prove that > the reauth initiator is the same entity as he was before. It also > would reduce the variety of collision cases substantially. That > sounds very attractive. Offhand, I can't think of any reason not to do it. Actually, one down-side does come to mind. RFC5996-style reauthentication and the kind described in my draft both allow the IKE SA attributes such as the encryption algorithm to be changed by virtue of the new IKE_SA_INIT exchange. That capability would be lost with IKE_AUTH on the old IKE SA. I wouldn't want to take that capability away. To affect an IKE SA policy change you'd have to deactivate/reactivate.
> > > > > I had considered this when making 4478, and the only thing that > > "blocked" me was that I couldn't figure out what to sign in the AUTH > > payloads. In regular IKE, they sign the IKE_SA_INIT messages, and I > > didn't like the idea of storing those for the lifetime of the IKE > > SA. Perhaps we could store the contents of the previous AUTH payload > > (or a hash thereof) and sign that. > Choosing suitable material to sign for a modified IKE_AUTH is not > really my strong point. Scott Moonen and Dave Wierbowski are > colleagues of mine and I suspect they would have good input here. > I'll ask them. Scott responded and said, "I can't think of a problem with Yoav's idea of signing the previous Auth payload." > > > > > On Oct 6, 2010, at 11:17 PM, Keith Welter wrote: > > > > > > > > Yoav Nir <y...@checkpoint.com> wrote on 10/05/2010 07:33:33 AM: > > > > > > > Hi Keith. > > > > > > > > After reading your draft, I wish I had done this in RFC 4478. > > > That's encouraging. Thanks. > > > > > > > Still, I have some comments. > > > > > > > > What are the considerations for the responder accepting a re- > > authentication? > > > > > > > > Suppose we have an active IKE SA between Alice and Bob. Now Bob > > > > gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs > > > > for the old IKE SA. When should Bob accept? When should Bob > > > > decline? What if later (in the IKE_AUTH exchange) the authenticated > > > > identity turns out to be Mallory? > > > Interesting question. Would you say that the same problem exists > > for re-authentication as defined in RFC 5996? > > > > In RFC 5996, the new IKE SA does not inherit the old child SAs. New > > child SAs will be created according to the policy relevant to Mallory. > > > > > It seems to me that in general there is nothing but local policy > > to stop a different IKE peer from establishing a child SA with the > > same traffic selectors as an existing child SA. So I wonder what > > makes that different from moving an existing child SA to a new IKE > > SA with a different peer. Can you describe a problem that would > > occur with moving a child SA that would not occur with RFC 5996- > > style reauthentication? > > > > The problem is having a child SA that belongs to Mallory, that is > > not allowed by policy (for Mallory). Another problem is one user > > getting another user's IP address, because the servers behind the > > gateway often rely on IP address for continuation of a session. One > > way is that when inheriting the child SAs, the IKE implementation > > goes over them, and only transfers those that agree with policy. > > That might work for inter-domain, but with remote access, there's > > usually no pre-defined policy as to what selectors are allowed forthe user. > > > > As Tero pointed out, re-authenticating implies also inheriting the > > assigned IP address, so I really think you need to set rules (or at > > least guidance) about the relationship between the old and new > > authenticated identity (is "Alice" with a password the same as the > > user who presents a certificate with "CN=Alice,OU=Users"? What > > about same DN but a different certificate?) > > > > > > > > > > > > > The way the draft is now, anyone can probe for the existence of IKE > > > > SPIs by sending IKE_SA_INIT requests with arbitrary IKE SPIs in the > > > > REAUTH_SA notification. This is not a particularly useful attack, > > > > but no need to expose ourselves to it. I think it would be better to > > > > move the notifications to the IKE_AUTH exchange. > > > Good point about the potential for SPI probing. > > > > > > My first version (unpublished) of the draft actually had the > > REAUTH_SA notification in the IKE_AUTH exchange. There were three > > advantages I saw for including the REAUTH_SA notification in the > > IKE_SA_INIT exchange instead. The main advantage was that I could > > use the presence of the REAUTH_SA notification in the IKE_SA_INIT > > request to signal usage of the IKE_AUTH exchange described in the > > draft that adds no additional children. Even though the child SA > > piggy-backed on the IKE_AUTH exchange doesn't cost any additional > > round-trips it does cost additional CPU that is unnecessary. And, > > to be tidy, one would also need to delete the old child SA that was > > re-negotiated before moving all the remaining children to the new > > IKE SA. So, eliminating the piggy-backed child SA this way seemed > > like a very attractive enhancement. > > > > The childless notification can be used for signaling, and I agree > > with Yaron, that support for REAUTH_SA can be signaled in the > > original IKE_AUTH. > > > > > > > > The second advantage I saw to including the notification in the > > IKE_SA_INIT exchange was that it eliminated an obscure collision > > case. The collision case was awkward to describe but I still have > > the text for it. To be clear, this was written for the version in > > which the IKE_AUTH exchange carried the REAUTH_SA notification: > > > If a peer receives a request to reauthenticate an IKE SA for which it > > > has not yet sent a request to reauthenticate, but has sent the > > > IKE_SA_INIT request with intent to reauthenticate, it SHOULD reply as > > > usual but SHOULD NOT include the REAUTH_SA notification in the > > > IKE_AUTH request that it will send and SHOULD close the new IKE SA it > > > creates after it receives the IKE_AUTH response. > > > > I think you can require never to send a REAUTH_SA if you have > > already received one from the peer. If that means leaving a half- > > open SA, so be it. RFC 5996 already requires implementations to > > handle these cases, and you can reduce them with guidance for > > original initiators to re-authenticate earlier than original responders. > > > > This leaves just the case of both sides having performed the > > IKE_SA_INIT, and sending the IKE_AUTH request before either receives > > the other IKE_AUTH request. This can be handled by having the one > > with lower Initiator SPI win, while the other exchange gets some > > error message (no proposal chosen? or a new one?) > > > > > > > > That text hints at the third and final reason. With the REAUTH_SA > > notification in the IKE_AUTH exchange, one doesn't know that a new > > IKE SA is reauthenticating an old IKE SA until the IKE_AUTH exchange > > begins. Alternatively, with the REAUTH_SA in the IKE_SA_INIT > > exchange, one knows immediately, from the very first IKE message, > > whether or not a given IKE SA is intended to reauthenticate another > > IKE SA or not. Whether or not removing this ambiguity is really an > > advantage or a disadvantage is debatable I suppose. > > > > OK. I'll debate for the other side. There's no reason to expose to > > eavesdroppers that we're doing a re-authentication. IKE_AUTH is > > encrypted, while IKE_SA_INIT is not. > > > > > > > > I'm not sure those three reasons outweigh your SPI probing > > concern. I'm assuming there is not already a way to probe for SPIs > > without the REAUTH_SA (I did a quick review of RFC 5996 from that > > angle and couldn't see another way to accomplish such a probe). If > > I could still omit the piggy-backed child SA from the IKE_AUTH > > exchange for a reauthentication I would be happy to move the > > notification back to the IKE_AUTH exchange where I originally had it. > > > > > > > Once there, the intuitive logic would be: > > > > - If the peer authenticates as other than Alice, deny REAUTH (fail > > > > the exchange?) > > > > - If authentication fails, ignore it. The old IKE SA remains alive. > > > > - If the peer authenticates as Alice, allow the reauth. > > > > > > > > This leads me to another issue. If the peer authenticates as Alice, > > > > we can treat it as an "Alice". Is it OK for "an Alice" to inherit > > > > the child SAs of any other "Alice"? Ideally, there is only one > > > > "Alice" and if the peer authenticates as "Alice" it may inherit any > > > > child SAs belonging to any IKE SA belonging to "Alice", but I think > > > > it would be better to somehow tie the old SA to the new SA with non- > > > > public information. Perhaps something derived from the SKEYSEED > > > > along with SK_d and the rest. > > > I'll defer to Yaron's response here though I'd still like to > > understand if this issue is really isolated to the proposed movement > > of child SAs for reauthentication as I asked above. > > > > If I connect to work from both computer and my phone, should the > > phone be able to "steal" the computer's SAs? If IKE is ever > > integrated with NEA work, it might imply moving SAs that were > > created with one posture to a host with another posture. Without > > NEA, it's not so much a security issue, as it is a networking issue. > > > > > > > > > > > > > One final issue. The IKE_AUTH exchange in your draft does not > > > > include what's needed for creating new Child SAs. This is not > > > > allowed by RFC 5996. There is, however, a soon-to-be-published RFC > > > > for this (draft-nir-ipsecme-childless) > > > I was aware of this draft. Assuming we conclude that it would be > > best to move the REAUTH_SA notification to the IKE_AUTH exchange > > then I would want to refer to that document and specify that it's > > mechanisms be used to avoid creating an additional child SA when > > reauthenticating an IKE SA. However, I'm not clear why the approach > > described in the current version of my draft is a not an acceptable > > way to specify a childless IKE_AUTH exchange. > > > > > > > > > > > Yoav > > > > > > > > On Sep 28, 2010, at 10:03 PM, Keith Welter wrote: > > > > > > > > > > > > > > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has > > > > been successfully submitted by Keith Welter and posted to the > > IETF repository. > > > > > > > > > > Filename: draft-welter-ipsecme-ikev2-reauth > > > > > Revision: 00 > > > > > Title: Reauthentication > > > > Extension for IKEv2 > > > > > Creation_date: 2010-09-28 > > > > > WG ID: Independent Submission > > > > > Number_of_pages: 10 > > > > > > > > > > Abstract: > > > > > This document extends the Internet Key Exchange (IKEv2) Protocol > > > > > document [IKEv2]. IKEv2 reauthentication does not scale well when an > > > > > IKE SA has multiple Child SAs because each Child SA of the IKE SA to > > > > > be reauthenticated must be renegotiated. In addition, > > > > > reauthentication is susceptible to the same kinds of exchange > > > > > collisions as those that may occur during rekeying. This document > > > > > describes a mechanism to detect reauthentication and avoid > > > > > renegotiating the Child SAs. In addition, this document describes > > > > > proper handling of exchange collisions that may occur during > > > > > reauthentication. > > > > > > > > > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > > > > > > > > > > > > <ATT00001..txt> > > > > > > > > > > > > > Scanned by Check Point Total Security Gateway. > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
