Subject: [MSEC] GDOI Update

From: Brian Weis <[email-masked]>
Date: Thu, 26 Sep 2002 18:13:28 -0700

A new draft of GDOI is being prepared which adds some clarification
text. This mail describes that clarification. Feedback is welcomed.

The GDOI draft describes two protocols: the GROUPKEY-PULL registration
protocol which is protected by a "phase 1" protocol, and the
GROUPKEY-PUSH rekey message which stands alone.  The rest of this email
is in relation to the GROUPKEY-PULL registration protocol.

As defined in draft-ietf-msec-gdoi-05.txt, the "phase 1" protocol
protecting GROUPKEY-PULL is specified to be the Phase 1 protocol
definitions from RFC 2409. It also describes the specific requirements
placed on those protocols. This will not change. However, GDOI itself
has no unique dependency on these Phase 1 protocol definitions, and in
fact other protocols could be used instead. As long as a protocol
satisfies the security requirements, it is an acceptable choice.

The next draft will clarify the role of the Phase 1 protocol, and also
will sketch out how two other potential "phase 1" protocol definitions
could be used to protect the GDOI protocol.

Following is the proposed section describing the requirements for the
phase 1 protocol. This expands the text found in section 2.0 of
draft-ietf-msec-gdoi-05.txt.

2.0 GDOI Phase 1 protocol

   GDOI is a "phase 2" protocol which MUST be protected by a "phase 1"
   protocol. The "phase 1" protocol can be any protocol which provides
   for the following protections:

   o Peer Authentication
   o Confidentiality
   o Message Integrity

   The following sections describe one such "phase 1" protocol. Others
   protocols which may be potential "phase 1" protocols are described in
   Appendix A.

2.1 ISAKMP Phase 1 protocol

   This document defines how the ISAKMP phase 1 exchanges as defined in
   [RFC2409] can be used a "phase 1" protocol for GDOI. The following
   sections define characteristics of the ISAKMP phase 1 protocols that
   are unique for these exchanges when used for GDOI.

   Section 6.1 describes how the ISAKMP Phase 1 protocols meet the
   requirements of a GDOI "phase 1" protocol.

2.1.1 DOI value

   The Phase 1 SA payload has a DOI value. That value MUST be the GDOI
   DOI value as defined later in this document.

2.1.2 UDP port.

   GDOI MUST NOT run on port 500 (the port commonly used for IKE). A new
   port number MUST be defined by IANA for GDOI.

An appendix is added which sketches out two additional possible phase 1
protocols.  These sketches are intended to be examples, not actual
protocol definitions.

Appendix A: Alternate GDOI Phase 1 protocols

   This section describes a manner in which other protocols could be
   used as GDOI Phase 1 protocols in place of the ISAKMP Phase 1
   protocol. However, a separate document MUST be written in order for
   another protocol to be used as a GDOI Phase 1 protocol.

   Any GDOI phase 1 protocol MUST satisfy the requirements specified in
   Section 2 of this document.

A.1 IKEv2 Phase 1 protocol

   Version 2 of the IKE protocol (IKEv2) is a work in progress [IKEv2].
   That protocol seeks to simplify the IKE Phase 1 and Phase 2
   protocols, and improve the security of the IKE protocol. An IKEv2
   Phase 1 negotiates an IPSEC SA during phase 1, which was not possible
   in IKE. However, IKEv2 also defines a phase 2 protocol. The phase 2
   protocol is protected by the Phase 1, similar in concept to how IKE
   Quick Mode is protected by the IKE Phase 1 protocols in [RFC2409].

   IKEv2 may not include a DOI value in the SA payload. However, since
   GDOI uses a unique port, choice of a phase 2 protocol in the SA
   payload using a GDOI value is not necessary. It is expected that an
   IKEv2 Phase 1 protocol definition could be run on the GDOI port.
   The SA payload in the protocol would be specific to GDOI, or omitted
   if not needed at all.

   The GROUPKEY-PULL protocol would follow the IKEv2 Phase 1 protocol in
   the same manner as described in this document.

A.2 KINK Protocol
   A work in progress [KINK] has defined a method of encapsulating an
   IKE Quick Mode [RFC2409] encapsulated in Kerberos KRB_AP_REQ and
   KRB_AP_REP payloads. KINK provides a low-latency, computationally
   inexpensive, easily managed, and cryptographically sound method of
   setting up IPSec security associations.

   The KINK message format includes a GDOI field in the KINK header. The
   [KINK] document defines the DOI for the IPSEC DOI.

   A new DOI for KINK could be defined which would encapsulate a
   GROUPKEY-PULL exchange in the Kerberos KRB_AP_REQ and KRB_AP_REP
   payloads. As such, GDOI would benefit from the computational
   efficiencies of KINK.

Comments?
Brian

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 27 Sep 2002 11:56:20 -0400

Brian,

I think we will be better of specifying ONE protocol for phase 1, and 
ISAKMP Phase 1 sounds good.  IKEv2 in the appendix is also welcome, 
since that looks like the evolutionary path.  But, I would strongly 
suggest against specifying options for phase 1 in GDOI.  We may end up 
with GDOI implementations that do not interoperate with each other.

I did notice that you used the word "examples" for the protocols (to be) 
listed in the Appendix, but why risk ambiguity.  Instead, we might put 
these options in the GKMArch draft, if necessary.

cheers,
Lakshminath