[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    [IPsec]  Comment on ikev2bis section 2.4
From:       Tero Kivinen <kivinen () iki ! fi>
Date:       2008-09-26 9:12:31
Message-ID: 18652.42879.953190.973639 () fireball ! kivinen ! iki ! fi
[Download RAW message or body]

Keith Welter writes:
> >From ikev2bis section 2.4:
>    {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this
>    IKE_SA is the only IKE_SA currently active between the authenticated
>    identities.  It MAY be sent when an IKE_SA is established after a
>    crash, and the recipient MAY use this information to delete any other
>    IKE_SAs it has to the same authenticated identity without waiting for
>    a timeout.  This notification MUST NOT be sent by an entity that may
>    be replicated (e.g., a roaming user's credentials where the user is
>    allowed to connect to the corporate firewall from two remote systems
>    at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification,
>    if sent, MUST be in the first IKE_AUTH request, not as a separate
>    exchange afterwards; however, receiving parties need to deal with it
>    in other requests.
> 
> How can the assertion described in the first sentence be made by the 
> sender of the IKE_AUTH request since the identities are not authenticated 
> until the IKE_AUTH response is received?

I have implemented it so that we do do mark the initial contact being
received when we see the notification, and then when the full IKE SA
negotiation is finished (i.e. authenticated successufully), we
process the INITIAL_CONTACT notification.

Of course you should not act on the INITIAL_CONTACT immediately, but
only after the other end is authenticated himself. If the initiator is
using EAP to authenticate him, then he is authenticated only after
last IKE_AUTH request is processed.

> Furthermore, it seems that even if the "authenticated" condition is
> dropped from the first sentence, the IKE_AUTH request would need to
> contain the optional IDr payload in order for INITIAL_CONTACT to
> make sense in this message.

The first IKE_AUTH request from initiator to responder will have the
IDi, which gives the identity of the initiator, and if there is
INITIAL_CONTACT notification in the same packet the responder will
know that the identity of the other end will be IDi after the full
authentication is finished. If no EAP is used, then the responder can
immediately process the AUTH payload too, and will authenticate the
other end while processing the request. If EAP is used, then initiator
will be authenticated only at the last IKE_AUTH request, thus
processing of the INITIAL_CONTACT should be postponed until that. It
still makes sense to send the INITIAL_CONTACT in the same packet where
the IDi is sent, thus thats why it is sent inside the first IKE_AUTH
message.

For the responder to send INITIAL_CONTACT to initiator is usually not
that useful, as initiator already told the responder that he most
likely do not have valid IKE SA with the responder, because he started
the IKE SA creation in the first place.

The current text added by the clarification actually forbids responder
for sending INITIAL_CONTACT, as it says the INITIAL_CONTACT MUST be in
the first IKE_AUTH *request*, which means it cannot be in the IKE_AUTH
reply sent back by the responder.
-- 
kivinen@safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]