Subject: RE: [Ipsec] Reauthentication in IKEv2

From: [email-masked]
Date: Thu, 28 Oct 2004 09:25:36 +0300

Hi,

Do you mean reauthentication or rekeying an IKE SA?

These are not the same in IKEv2: although reauthentication
always does rekeying as well, the reverse is not true; and 
there are two separate lifetimes ("key lifetime" can be 
shorter than "authentication lifetime"). 

CREATE_CHILD_SA exchange is related to rekeying without
reauthentication, so EAP is not involved. Reauthentication is
done by establishing a new IKE SA from scratch, creating new
child SAs (equivalent to the old ones), and finally deleting 
the old IKE SA.

For policy lookups, it's very important to use the identity
(identifier) that was actually authenticated by the EAP method,
and this is not necessarily the same as IDi. Many EAP methods
have an internal identity exchange, and the initial identity
(e.g., IDi or EAP Identity Response) is used only for AAA
routing and selecting which method to use (see RFC 3748,
sections 5.1 and 7.3). "Reauthentication identities" in some 
EAP methods are an obvious example where using IDi for policy 
lookups fails, but that's not the main reason.

Best regards,
Pasi

> -----Original Message-----
> From: Jyothi
> Sent: Thursday, October 28, 2004 7:06 AM
> To: [email-masked]
> Subject: [Ipsec] Reauthentication in IKEv2
> 
> 
> Hi all,
> 
> I have some questions regarding the Reauthentication in IKEv2.
> 
> 1. CREATE_CHILD_SA exchange is supported.
> 
> In this when the IKE SA lifetime is completed, we use
> CREATE_CHILD_SA exchange and form new IKE SA keys.
> 
> Is it required to reauthenticate the peer may be after some
> time???
> 
> If reauthentication is required, in case of EAP
> authentication, it says that CLIENT may use the EAP Fast
> reauthentication ID in IKE exchange.
> 
> In this case IKE policy lookup may fail, if we are searching
> with the received identity.
> 
> If reauthentication is required, what is the best way to proceed??
> 
> May be the responder has to maintain some mapping between
> policy identity and EAP negotiated identity.
> 
> 2. CREATE_CHILD_SA exchange is not supported
> 
> In this case, peer will always authenticate.
> 
> If EAP authentication is used, do we have to go for EAP 
> re-authentication???
> 
> Awaiting your responses.
> 
> Thanks in advance,
> Jyothi

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Oct 2004 12:54:06 +0300

Hi Pasi,

> lookups fails, but that's not the main reason.

I agree, but is this specified somewhere? RFC2401bis-04 has
this text:

          1. A named SPD entry is used by a responder (not an initiator)
             in support of access control when an IP address would not be
             appropriate for the Remote IP address selector, e.g., for
             "road warriors."  The name used to match this field is
             communicated during the IKE negotiation in the ID payload.
             In this context, the initiator's Source IP address (inner IP
             header in tunnel mode) is bound to the Remote IP address in
             the SAD entry created by the IKE negotiation. This address
             overrides the Remote IP address value in the SPD, when the
             SPD entry is selected in this fashion.  All IPsec
             implementations MUST support this use of names.

This seems to talk about the ID payload, not the value communicated
from the AAA server. Does the text need to be updated, or am I
missing something?

Secondly, the remote (inner) IP address presumably
may come from RADIUS too?

Finally, I wonder how the named SPD entry setup should be administered.
Lets assume there are a million potential users in the service
provider's RADIUS (or Diameter) database. Is there going to have to
be a million SPD entries too in the gateway, or an the RADIUS responses
point to a "class" entry for a particular type of a user (e.g.,
"subscriber" and "administrator")?

--Jari