GSAKMP: Group Secure Association Key Management Protocol
draft-ietf-msec-gsakmp-sec-10

[Ballot comment]
sent:

Sent:

Russ, Ran and Lakshminath,

The new IANA rules  make the extensibility much
more appropriate to the protocol security.  Thanks!

I've copied IANA so that the change can be flagged, since
I instigated it.

Since you have specified Expert Review for some of the fields,
I want to draw your attention to a suggestion:  it's a good
thing to appoint the Expert Reviewer (or two, a Primary and
Secondary) now, before the approval goes out, and have it
included in the IANA Note on the announcement, so this
important step gets handled very transparently (and not
forgotten).

My clearing isn't gated on it (I'm done, bye :) 

I'm suggesting you guys and IANA get this done before Russ
sends in the final approve...

Not sent:  I re-reviewed Vendor ID - it seems safe enough to me; it seems an
unscrupulous extender would not exploit it very easily.

[Ballot discuss]
The IANA Considerations grants extensibility entirely by Specification Required.
This means that this secure protocol can be made insecure because any old
document, with only an IANA check that there is some document, is needed to
add features to it.  It seems like a bad idea not to require IETF review for the
extensions for a Proposed Standard security protocol that will be used for
signification applications.  Please the extensibility policies to IETF Consensus.

------------

The stuff below has been handled:



Something easy enough to fix, but needs fixing: 

For example, in a small-scale video
conference the organizer might use a session invitation protocol like SIP
[RFC 2543] to transmit information about the time of the conference, the
address of the session, and the formats to be used.  For a large-scale video
transmission, the organizer might use a multicast announcement protocol like
SAP [RFC 2974].

The reference for SIP is now RFC 3261, though it is not so straightforward to
pass the information for multi-point with SIP, and doing so is not really covered
in 3261.  The work that covers it is draft-ietf-sipping-conferencing-framework.

[Ballot discuss]
Worried about the Specification Required in IANA Considerations

------------

The stuff below is ok:



Something easy enough to fix, but needs fixing: 

For example, in a small-scale video
conference the organizer might use a session invitation protocol like SIP
[RFC 2543] to transmit information about the time of the conference, the
address of the session, and the formats to be used.  For a large-scale video
transmission, the organizer might use a multicast announcement protocol like
SAP [RFC 2974].

The reference for SIP is now RFC 3261, though it is not so straightforward to
pass the information for multi-point with SIP, and doing so is not really covered
in 3261.  The work that covers it is draft-ietf-sipping-conferencing-framework.

[Ballot comment]
Lots or review comments from John Loughney, but none of them look like show-stoppers:

Review of draft-ietf-msec-gsakmp-sec-08.txt

Summary:

This is generally ready for publication as a proposed standard.  The Vendor ID Payload
is my biggest open issue, however I am not sure how this should be resolved. Some nits were
found, but these could be updated if the document is revised.  The document
was well written and I appreciated the list of figures and tables.  Please note
that this is an area outside of my area of expertise, so I assume that the terminology,
etc. are well known within the documents target audience.  One general request that
I would have would be the expansion of acronyms in section titles, such as:

4.4.2 Creation of a PT

  - would become:

4.4.2 Creation of a Policy Token

Just as there is a lot of acronyms and I found that I had to keep refering back to
Chapter 2 Terminology (which doesn't contain all fo the acronyms, by the way).
 
Questions:

1) Section "3.2.3 LKH" says:

When group policy dictates that a recovery of the group security is
necessary after the discovery of the compromise of a GM, then GSAKMP
relies upon a rekey capability, i.e., LKH, to enable group recovery after
a compromise [RFC 2627].  This is optional since in many instances it may be
better to destroy the compromised group and rebuild a secure group.

but then section "3.4 Rekey Availability"

In addition to GSAKMP having the capability to do rekey operations, GSAKMP
MUST also have the capability to make this rekey information highly
available to GMs.  The necessity of GMs receiving rekey messages, requires
the use of methods to increase the likelihood of receipt of Rekey Messages.
These methods MAY include multiple transmissions of the rekey message,
posting of the rekey message on a bulletin board, etc.  Compliant GSAKMP
implementations MUST support retransmission of rekey messages.

Section 3.2.3 seems to indicate that rekeying is optional but 3.4 has a MUST for
the retransmission of rekey messaging.  My question is, is the rekeying operation
mandatory or optional?  Or is it just that after a group is compromised, it is
optional to rekey, as it may be preferable to destroy the group entirely?  The
current text is not so clear.

2) General question on Vendor-ID payload, secton 7.10:

Writers of Internet-Drafts who wish to extend this protocol MUST define a
Vendor ID payload to announce the ability to implement the extension in the
Internet-Draft.  It is expected that Internet-Drafts which gain acceptance
and are standardized will be given assigned values out of the Reserved to
IANA range and the requirement to use a Vendor ID payload will go away.

I had a little trouble parsing this.  Does this mean that Vendor-IDs should
generally be written-up as Internet drafts?  Should there be a registry
for the vendor payloads?  Additionally, the packet format doesn't say
what the VID is. 

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !  RESERVED    !        Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                        Vendor ID (VID)                      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Should this be using the IANA assigned "SMI Network Management Private Enterprise
Codes"?


Small nits:

1) Shouldn't Abstract be left justified?
2) Text needs to be indented in most places.
3) Double spacing before and after section headings should be changed
  to single spacing.
4) CRL is used in section 3.1, item 8, but I couldn't find an expansion
  on what CRL is.
5) Expansion of some protocols like ISAKMP, FIPS Pub 196, LKH etc. would
  be helpful.
6) In many places, the ` is used, shouldn't ' be used instead? Also,
  `` and '' is used, but shouldn't " be used instead?

Ran idnits script and found the following nits:

idnits 1.61
  Checking nits according to http://www.ietf.org/ID-Checklist.html :

    Checking conformance with RFC 3978/3979 boilerplate...
  * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
    Acknowledgement  -- however, there's a paragraph with a matching beginning.
    Boilerplate error?
  * The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure
    Acknowledgement.
  * The document seems to lack an RFC 3979 Section 5, para 2 IPR Disclosure
    Acknowledgement.
  * The document seems to lack an RFC 3979 Section 5, para 3 IPR Disclosure
    Invitation.
  * There are 1222 instances of too long lines in the document, the longest
    one being 8 characters in excess of 72.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

  * The document seems to lack a 1id_guidelines paragraph about 6 months
    document validity -- however, there's a paragraph with a matching beginning.
    Boilerplate error?

  Miscellaneous warnings:

  - The "Author's Address" (or "Authors' Addresses") section title is
    misspelled.

    Run idnits with the --verbose option for more detailed information.

[Ballot discuss]
Something easy enough to fix, but needs fixing: 

For example, in a small-scale video
conference the organizer might use a session invitation protocol like SIP
[RFC 2543] to transmit information about the time of the conference, the
address of the session, and the formats to be used.  For a large-scale video
transmission, the organizer might use a multicast announcement protocol like
SAP [RFC 2974].

The reference for SIP is now RFC 3261, though it is not so straightforward to
pass the information for multi-point with SIP, and doing so is not really covered
in 3261.  The work that covers it is draft-ietf-sipping-conferencing-framework.

[Ballot comment]
This protocol contains many optional out of band features like
eviction of members.  Similarly, finding subordinate GC/KS may be
challenging.  It will be difficult to get multiple interoperable
implementations of all these features and advance the protocol to draft
standard.

I'm surprised that the protocol mandates neither AES nor RSA.


The protocol does a good job of meeting its requirements and for
relatively high security need/high infrastructure group management
this protocol is a good fit.  I think the IETF has need of a group SA
management protocol that works in less rigorous environments.  AS an
example I don't think this protocol would be appropriate for OSPF v3
or for other routing/ops area needs.  I think that the same pressures
that required us to add EAP support to IKEV2 will require us to
provide a group management protocol that supports whatever credentials
the deployment environment happens to have.  It's not a problem with
this protocol that those needs are not met; we just have more work to
do.  Also, I realize that making a variant of this protocol that met
those needs would be relatively easy.

[Ballot discuss]
The protocol seems to have no mandatory to implement mechanism for
discovering GC/KS.  I suggest mandating at least manual configuration in order to guarantee interoperability.

How does a GM know whether a nonce needs to be included in an RTJ
message?  The protocol says that whether nonces (or timestamps) are
included is a property of the PT.  However the GM doesn't get the PT
until after the RTJ is sent.  Section 5.2.1.1 needs to provide
guidance on this issue.



The specification requires that only one RTJ message can be
outstanding for a given GM at a time.  It seems like the GK/CS is
expected to enforce this requirement.  What happens if a GM reboots or
otherwise loses state in the middle of joining a group?  How do things
get back into sync?

[Ballot comment]
In 7.6.1, the draft says:

DN Data (variable length)  -- The actual UTF-8 DN value (Subject
    field) using the slash (/) character for field delimiters.  (e.g.,
    "/C=US/ST=MD/L=Somewhere/O=ACME, 
Inc./OU=DIV1/CN=user1/Email=user1@acme.com"
    without the surrounding quotes)

Would it be beneficial to add  a pointer to the specific DN format required here?
I'm thinking, for example, of the discussion we just had relative to
draft-ietf-ldapbis-dn-15.txt.

[Ballot comment]
Section 7.7.2 says:
  >
  > Certificate Data - This Certificate Data MUST be processed according to
  > the certificate type specified.  The type will define the format of the
  > data.  Receipt of a root CA certificate in a Certificate payload causes
  > the payload to be discarded.  This received certificate MUST NOT be used
  > to verify the message.  The root CA certificate MUST be retrieved by
  > other means.
  >
  Please say "certificate of the trusted policy creation authority" instead
  of "root CA certificate."