Subject: Re: [MSEC] GDOI Update

From: Ran Canetti <[email-masked]>
Date: Sat, 28 Sep 2002 06:01:51 -0400

Just a clarification:

The suggested additions to the GDOI document are a result of concerns expressed
recently regarding whether GDOI violates the "moratorium" that the ADs
imposed last summer on developing new protocols based on IKEv1. In a
discussion between the ADs, the WG chairs, and the authors of GDOI, it was
agreed that GDOI will add language that will make it clear that GDOI is not
just and extenstion of IKEv1, but rather it can be based on any "phase 1"
protocol that provides some basic security proerties. Furthermore, when
IKEv2 will stabilize, the GDOI document (or a subsequent document) will 
specify how exactly to use GDOI with ikev2-based phase 1.

It is my understanding that text below posted by Brian is a result of
this agreement. (Correct me if I'm wrong, Brian.)

Any further remarks from the WG are welcome.

Ran

> From: Lakshminath Dondeti <[email-masked]>
> 
> 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
> 
> Brian Weis wrote:
> > 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
> > 
> 
> 
> 

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