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
