[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-msec-gdoi-07 versus 08 version
- To: RFC Editor <rfc-editor@rfc-editor.org>, "Steven M. Bellovin" <smb@research.att.com>, Joyce Reynolds <jkrey@ISI.EDU>, mbaugher@cisco.com, housley@vigilsec.com, thardjono@verisign.com, hh@sparta.com, canetti@watson.ibm.com, iesg@ietf.org, iana@iana.org, iesg-secretary <iesg-secretary@ietf.org>
- Subject: Re: draft-ietf-msec-gdoi-07 versus 08 version
- From: Brian Weis <bew@cisco.com>
- Date: Tue, 17 Jun 2003 02:37:09 -0700
- References: <20030512174332.732A37B4D@berkshire.research.att.com> <20030512193916.GE9271@isi.edu> <3EC00198.B1A2147B@cisco.com>
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