Subject: Document Action: 'Repeated Authentication in IKEv2' to Experimental RFC

From: The IESG <[email-masked]>
Date: Mon, 20 Feb 2006 14:21:58 -0500

The IESG has approved the following document:

- 'Repeated Authentication in IKEv2 '
   <draft-nir-ikev2-auth-lt-05.txt> as an Experimental RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Russ Housley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-05.txt

Technical Summary

  This document describes an extension to the IKEv2 protocol that allows
  an IKEv2 implementation to request that a peer repeat the Initial and
  Authentication exchanges within a certain period of time, or else the
  existing IKE SA may be closed or blocked for subsequent SA creation.

  This IKEv2 extension is needed for cases where it is impossible for
  one peer to initiate the Authentication exchange.  Examples of such
  situations are:
     - An EAP authenticator can not be the initiator in an AUTH exchange.
     - When the peer requires user intervention to authenticate, such as
       entering a shared secret or plugging in a hardware token, an IKE
       exchange may time out.

  In these situations, the original responder cannot initiate an Initial
  and Authentication exchange, so it has to request this from the peer.

Working Group Summary

  This document specifies a solution to a situation that was recognized
  by the IPsec WG.  However, there was some controversy about the
  solution proposed.  This document allows the IKEv2 implementation to
  send an AUTH-LT message either in the original AUTH exchange, or in a
  separate INFORMATIONAL exchange, which is an immediate request for
  re-authentication.

  Some people agreed with specifying both options, but others preferred
  specifying just one of the options.  The later group voiced a
  preference for fewer protocol variations.

  One expert objected to having the notification in the original AUTH
  exchange because of a general objection to having timers in the
  protocol.  This is a strong preference for a separate informational
  exchange, only supporting the re-authenticate now protocol variation.

  Here is a link to the discussion on the IPSec list:
  http://www.vpnc.org/ietf-ipsec/mail-archive/threads.html#02139

Protocol Quality

  While this is an individual submission, the protocol extension has
  been discussed on the IPsec WG mail list.

  No deployed implementation are known, although at least one
  implementation is under development by the author.

  This document was reviewed by Russ Housley for the IESG.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce