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?
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. 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 for the 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
