On Oct 5, 2010, at 7:48 PM, Yaron Sheffer wrote: > Hi Yoav, > > you are discussing two separate issues related to identity: the "alleged > identity" (the name presented as IDi and/or authenticated by the > IKE_AUTH exchange) and the ability to correlate the two SAs using some > secret information. > > I think we should be flexible about the alleged identity. If Alice has > had a medical operation and is now Alistair, your policy might still > allow him to reuse the old SA. Some EAP methods support anonymity and > pseudonymity, and I don't think we want to force them to employ stable > identities.
All the more reason to have set rules on when a new IKE SA can inherit. > > But this implies that we need something else to ensure continuity of the > identity, and mixing the old SK_d into the new authentication certainly > makes sense. > > Thanks, > Yaron > > On 10/05/2010 04:33 PM, Yoav Nir wrote: >> Hi Keith. >> >> After reading your draft, I wish I had done this in RFC 4478. 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? >> >> 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. 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. >> >> 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) >> >> 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> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
