Re: draft-ietf-msec-gdoi-07 versus 08 version

[RFC Editor <rfc-editor@rfc-editor.org>]

Brian,

The changes submitted were sufficient.  We have incorporated the
altered text.

Thank you for the follow up.

RFC Editor


On Tue, Jun 17, 2003 at 02:37:09AM -0700, Brian Weis wrote:
> Hello RFC Editor,
> 
> Just wondering if the diffs attached to my original mail (sent about 1
> month ago) were easy enough for you to apply to -07, or would you like
> me to re-send them in an easier to read format?
> 
> Thanks,
> Brian
> 
> Brian Weis wrote:
> > 
> > Hello RFC Editor,
> > 
> > I'm the author who generated -08. I've attached the differences between
> > -07 and -08 in hopes it is useful to you. This was generated by the UNIX
> > "diff" tool, but I hope the changes are apparent to you. I've tried to
> > summarize the format of the file below.
> > 
> > Lines beginning with a "!" indicate a changed line. Lines not beginning
> > with a "!" have not changed, but are helpful in finding the changed
> > lines.
> > 
> > There are two blocks of text between  "************" lines. The first
> > block is the original text from version -07. This is followed by the new
> > text in version -08.
> > 
> > Please feel free to call me or send email if you have more questions. If
> > you can't make sense of the attached differences file, I can send you
> > the changes in whatever way is most useful to you. My contact
> > information is at the bottom of this email.
> > 
> > Thanks,
> > Brian
> > 
> > RFC Editor wrote:
> > >
> > > Steve,
> > >
> > > If the changes are minimal, do you think the authors would be willing
> > > to send us a list of changes during the authors 48 hours?  It would
> > > save a great deal of time in processing the document.
> > >
> > > RFC Editor
> > >
> > > On Mon, May 12, 2003 at 01:43:32PM -0400, Steven M. Bellovin wrote:
> > > > In message <200305121613.h4CGD9124712@boreas.isi.edu>, Joyce Reynolds writes:
> > > > >
> > > > >
> > > > >It would have been nice if the RFC Editor had known sooner to use
> > > > ><draft-ietf-msec-gdoi-08>, instead of the IESG approved (as a PS)
> > > > ><draft-ietf-msec-gdoi-07>.  We already did the editing and nroffing of
> > > > >the 07 version.  IANA just finished its work on this document and sent
> > > > >us a message on 6 May.  We were in final editing stages to publish.
> > > >
> > > > Sorry -- I blew the timing.  But the changes are fairly small; wdiff
> > > > might do the trick.
> > > > >
> > > > >So, version 08 is the version (which I note has a write day of 8 May)
> > > > >is the one the RFC Editor should be using.  Can the IESG-Secretary send
> > > > >RFC Editor a note directing us to use 08 instead of 07?
> > > > >
> > > > That should indeed be done.
> > > >
> > > >               --Steve Bellovin, http://www.research.att.com/~smb (me)
> > > >               http://www.wilyhacker.com (2nd edition of "Firewalls" book)
> > > >
> > 
> > --
> > Brian Weis
> > Strategic Cryptographic Development, ITD, Cisco Systems
> > Telephone: +1 408 526 4796
> > Email: bew@cisco.com
> > 
> >   ------------------------------------------------------------------------
> > *** /tmp/d1.3295        Thu May  8 14:56:41 2003
> > --- /tmp/d2.3295        Thu May  8 14:56:41 2003
> > ***************
> > *** 1,9 ****
> >      Internet Engineering Task Force                          Mark Baugher(Cisco)
> >      INTERNET-DRAFT                                    Thomas Hardjono (Verisign)
> >      Category: Standards Track                               Hugh Harney (Sparta)
> > !    Document: draft-ietf-msec-gdoi-07.txt                     Brian Weis (Cisco)
> > !    Expires: June, 2003
> > !                                                                  December, 2002
> >                       The Group Domain of Interpretation
> >   Status of this Memo
> >      This document is an Internet-Draft and is in full conformance with
> > --- 1,9 ----
> >      Internet Engineering Task Force                          Mark Baugher(Cisco)
> >      INTERNET-DRAFT                                    Thomas Hardjono (Verisign)
> >      Category: Standards Track                               Hugh Harney (Sparta)
> > !    Document: draft-ietf-msec-gdoi-08.txt                     Brian Weis (Cisco)
> > !    Expires: November, 2003
> > !                                                                       May, 2003
> >                       The Group Domain of Interpretation
> >   Status of this Memo
> >      This document is an Internet-Draft and is in full conformance with
> > ***************
> > *** 142,149 ****
> >      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.
> >   3.0 GROUPKEY-PULL Exchange
> >      The goal of the GROUPKEY-PULL exchange is to establish a Re-key
> >      and/or Data-security SAs at the member for a particular group. A
> > --- 142,149 ----
> >      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). IANA
> > !    has assigned port 848 for the use of GDOI.
> >   3.0 GROUPKEY-PULL Exchange
> >      The goal of the GROUPKEY-PULL exchange is to establish a Re-key
> >      and/or Data-security SAs at the member for a particular group. A
> > ***************
> > *** 511,528 ****
> >                  Identification (ID)            5
> >                  Nonce (N)                     10
> >      Several new payload formats are required in the group security
> > !    exchanges. The Payload types for the new headers are defined in the
> > !    ISAKMP "Private USE" range.
> >                  Next Payload Type            Value
> >                  -----------------            -----
> > !                RESERVED                   128 - 129
> > !                SA KEK Payload (SAK)          130
> > !                SA TEK Payload (SAT)          131
> > !                Key Download (KD)             132
> > !                Sequence Number (SEQ)         133
> > !                Proof of Possession (POP)     134
> > !                RESERVED                   135 - 200
> > !                GDOI Private Use           201 - 255
> >   5.1 Identification Payload
> >      The Identification Payload is used to identify a group identity that
> >      will later be associated with Security Associations for the group. A
> > --- 511,524 ----
> >                  Identification (ID)            5
> >                  Nonce (N)                     10
> >      Several new payload formats are required in the group security
> > !    exchanges.
> >                  Next Payload Type            Value
> >                  -----------------            -----
> > !                SA KEK Payload (SAK)          15
> > !                SA TEK Payload (SAT)          16
> > !                Key Download (KD)             17
> > !                Sequence Number (SEQ)         18
> > !                Proof of Possession (POP)     19
> >   5.1 Identification Payload
> >      The Identification Payload is used to identify a group identity that
> >      will later be associated with Security Associations for the group. A
> > ***************
> > *** 586,593 ****
> >          o RESERVED (1 octet) - Must be zero.
> >          o Payload Length (2 octets) is the octet length of the current
> >      payload including the generic header and all TEK and KEK payloads.
> > !        o DOI (4 octets) - Is the GDOI, which is value 196 pending
> > !    assignment by the IANA.
> >          o Situation (4 octets) - Must be zero.
> >          o SA Attribute Next Payload (1 octet) - Must be either a SAK
> >      Payload or a SAT Payload. See section 5.3.2 for a description of
> > --- 582,588 ----
> >          o RESERVED (1 octet) - Must be zero.
> >          o Payload Length (2 octets) is the octet length of the current
> >      payload including the generic header and all TEK and KEK payloads.
> > !        o DOI (4 octets) - Is the GDOI, which is value 2.
> >          o Situation (4 octets) - Must be zero.
> >          o SA Attribute Next Payload (1 octet) - Must be either a SAK
> >      Payload or a SAT Payload. See section 5.3.2 for a description of
> > ***************
> > *** 1386,1412 ****
> >      new policy and TEKs.
> >   7.0 IANA Considerations
> >   7.1 ISAKMP DOI
> > !    A new ISAKMP DOI number needs to be assigned to GDOI. RFC 2407
> > !    indicates that the namespace for DOI values is in STD-2, although
> > !    that does not yet exist such as section there. The present document
> > !    is in accordance with the "Supported Security Protocols" section in
> > !    [RFC2408].
> >   7.2 Payload Types
> > !    New ISAKMP Next Payload types need to be allocated for GDOI payload
> > !    types. No ISAKMP registry for payload types currently exists, but the
> > !    Private Use payload type namespace can be further partitioned for the
> > !    GDOI DOI. See Section 5.0 for the payloads defined in this document.
> >   7.3 New Name spaces
> >      The present document describes many new name spaces for use in the
> >      GDOI payloads. Those may be found in subsections under Section 5.0. A
> > !    new GDOI registry should be created for these name spaces.
> >      Portions of name spaces marked "RESERVED" are reserved for IANA
> >      allocation. New values MUST be added due to a Standards Action as
> >      defined in [RFC2434].
> >      Portions of name spaces marked "Private Use" may be allocated by
> >      implementations for their own purposes.
> >   7.4 UDP Port
> > !    A new UDP port is required for GDOI.
> >   8.0 Acknowledgements
> >      The authors thank Ran Canetti, Cathy Meadows, Andrea Colegrove, and
> >      Lakshminath Dondeti.  Ran has advised the authors on secure group
> > --- 1381,1403 ----
> >      new policy and TEKs.
> >   7.0 IANA Considerations
> >   7.1 ISAKMP DOI
> > !    An ISAKMP DOI number is needed to identify an SA payload as a GDOI SA
> > !    payload. The IANA has assigned the value 2 to represent GDOI.
> >   7.2 Payload Types
> > !    The present document defines new ISAKMP Next Payload types. See
> > !    Section 5.0 for the payloads defined in this document, including the
> > !    Next Payload values defined by the IANA to identify these payloads.
> >   7.3 New Name spaces
> >      The present document describes many new name spaces for use in the
> >      GDOI payloads. Those may be found in subsections under Section 5.0. A
> > !    new GDOI registry has been created for these name spaces.
> >      Portions of name spaces marked "RESERVED" are reserved for IANA
> >      allocation. New values MUST be added due to a Standards Action as
> >      defined in [RFC2434].
> >      Portions of name spaces marked "Private Use" may be allocated by
> >      implementations for their own purposes.
> >   7.4 UDP Port
> > !    The IANA has assigned port 848 for use by GDOI.
> >   8.0 Acknowledgements
> >      The authors thank Ran Canetti, Cathy Meadows, Andrea Colegrove, and
> >      Lakshminath Dondeti.  Ran has advised the authors on secure group
> 
> -- 
> Brian Weis
> Strategic Cryptographic Development, ITD, Cisco Systems
> Telephone: +1 408 526 4796
> Email: bew@cisco.com