Subject: RFC 4534 issues and errata

From: Alfred Hönes <[email-masked]>
Date: Thu, 9 Nov 2006 23:03:11 +0100 (MEZ)

Hello,
after studying the recently published RFC 4534 (Group Security
Policy Token v1)) authored by you, I would like to submit a few
comments, pointing out some issues I found with the RFC text,
and supplying material for an appropriate RFC Errata Note.

Items (4) and (5) below apparently are ASN.1 mistakes, and
as such should be corrected as soon as possible to further
interoperable implementation.
All other items are less significant and strictly editorial
in nature.

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(1)  on terminology

a)
The combination of the two roles of "Group Controller" and
"Key Server" is usually abbreviated as  "GC/KS" , and such
does RFC 4534.  Consistently, the full expansion should be
spelled  "Group Controller / Key Server"  to match the "/"
present in the acronym and to avoid the mis-understandable
unstructured word grouping, "Group Controller Key Server".

This affects Section 3.2, in the second line on page 7, and
the second line of Section B.1.1, on page 13.

b)
IMHO, the wording, "[the] rekey" is sluggish and should be
replaced by "[the] rekeying".
This affects the Section titles,
"3.3. Rekey Policy", that better should be: "3.3. Rekeying Policy"
as well as
    "B.5. GSAKMPv1 Rekey Policy"  and all
    "B.5.*. Rekey ___"  , and
    "B.6. GSAKMPv1 Rekey Policy ASN.1 Module"

Other changes:
  "rekey protocol" --> "rekeying protocol"  and
  "rekey message"  --> "rekeying message"    (Section 3, page 5),
  "Rekey SA"       --> "Rekeying SA"   and
  "During Rekey,"  --> "During Rekeying,"    (Section 3.3, page 7),
  "Rekey SAs"      --> "Rekeying SAs"        (Appendix B, page 13),
  "Rekey Protocol" --> "Rekeying Protocol" (2x) ,
  "rekey policy"   --> "rekeying policy"   (2x) ,
  "rekey messages" --> "rekeying messages" ,
  "rekey event"    --> "rekeying event"    (2x) ,
  "rekey message"  --> "rekeying message" ,
  "rekey interval" --> "rekeying interval" ,
  "rekey process"  --> "rekeying process" ,
  "the rekey"      --> "the rekeying" ,
  "rekey delivery" --> "rekeying delivery" ,
  "handle rekey."  --> "handle rekeying." ,  (all in B.5., on page 22),
  etc. ...
  "

(2)  typo (missing article)

In section 3.4, on page 8, the RFC says:

                                  [...].  There are several protocols
   that could make use of group keys, ranging from simple security
|  applications that only need key for encryption and/or integrity
   protection to more complex configurable security protocols such as
   IPsec and Secure Real-time Transport Protocol (SRTP) [RFC3711].  [..]

It should say:

                                  [...].  There are several protocols
   that could make use of group keys, ranging from simple security
|  applications that only need a key for encryption and/or integrity
   protection to more complex configurable security protocols such as
   IPsec and Secure Real-time Transport Protocol (SRTP) [RFC3711].  [..]

(3)  text formatting -- inappropriate indentation

Within Section B.1.3.1, the last paragraph on page 16 is unexpectedly
partially indented.
The RFC says:

   OpInfo provides configuration data for the operation of GSAKMP
       registration.  timeOut indicates the elapsed amount of time
       before a sent message is considered to be misrouted or lost.  It
       is specified as the timestamp type LifeDate, previously defined
       in the core token.  terse informs a GC/KS whether the group
       should be operated in terse (TRUE) or verbose (FALSE) mode.  The
       optional timestamp field indicates whether a timestamp (TRUE) or
       a nonce (FALSE) is used for anti-replay protection.  If the field
       is absent, the use of nonces is the default mode for GSAKMP
       registration.

It should say:

   OpInfo provides configuration data for the operation of GSAKMP
   registration.  timeOut indicates the elapsed amount of time before a
   sent message is considered to be misrouted or lost.  It is specified
   as the timestamp type LifeDate, previously defined in the core token.
   terse informs a GC/KS whether the group should be operated in terse
   (TRUE) or verbose (FALSE) mode.  The optional timestamp field
   indicates whether a timestamp (TRUE) or a nonce (FALSE) is used for
   anti-replay protection.  If the field is absent, the use of nonces is
   the default mode for GSAKMP registration.

(4)  omission in ASN.1 module

Section B.3, on pp. 20/21, gives a textual introduction with ASN.1
snippits to, and Section B.4, on pp. 21/22 gives the formal ASN.1
module for, GSAKMPv1 De-Registration.

Unfortunately, there's a significant inconsistency bewteen these
two sources of data structure and syntax.

On page 20, in Section B.3 the RFC says:

     GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
       leaveMechanisms  SEQUENCE OF LeaveMechanisms,
|      terse            BOOLEAN,
       transport        Transport
     }

On page 21, in Section B.4 the RFC says:

   GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
     leaveMechanisms SEQUENCE OF LeaveMechanisms,
     transport       Transport
   }

Obviously, the line
       terse            BOOLEAN,
has been lost on its way into the ASN.1 module, and should be
re-inserted to make it consistent with the text.

(5)  ASN.1 usage problems ??

a)
Section B.5.4, on page 24, defines:

     RekeyMethod ::= SEQUENCE {
       rekeyMethodType  OBJECT IDENTIFIER,
|      rekeyMethodInfo  OCTET STRING
     }

Why doesn't it use the "ANY DEFINED BY ..." syntax construct for
'rekeyMethodInfo' ?

Subsequent definitions in B.5.4.{1,2} define the syntax of
two possible instantiations of RekeyMethod, with syntax NULL
and INTEGER, respectively, for the rekeyMethodInfo element.
That doesn't match!

b)
Similarly, B.5.6, on page 25, defines:

     Reliability ::= SEQUENCE {
       reliabilityMechanism   OBJECT IDENTIFIER,
|      reliabilityMechContent OCTET STRING
     }

   The reliability mechanism is defined by an OBJECT IDENTIFIER and the
   information needed to operate that mechanism is defined as
|  reliabilityMechContent and is an OCTET STRING (as before).

whereas the subsequent definitions in B.5.6.{1,2,3} define the syntax
of three possible instantiations of Reliability, with syntax NULL,
INTEGER, and IA5String, respectively, for the reliabilityMechContent
element.
Again, that doesn't match!

c)
Finally, B.5.7, on page 26, defines:

     SubGCKSInfo ::= SEQUENCE {
       subGCKSScheme OBJECT IDENTIFIER,
|      sGCKSContent  OCTET STRING
     }

whereas the subsequent definitions in B.5.7.{1,2} define the syntax
of two possible instantiations of SubGCKSInfo, with syntax NULL and
SEQUENCE { ... }, respectively, for the sGCKSContent element.
Again, that doesn't match!

(6)  typos

a) Section B.5.4.1, on page 24, says:
                                           vv       vvv
|  The group defined to work without a rekey protocols supporting it is
   supported by the rekeyMethodType NONE.  [...]

It should say:
                                            vvvv       vv
|  The group defined to work without a rekeying protocol supporting it
   is supported by the rekeyMethodType NONE.  [...]

b) Section B.5.4.2, on page 24, says:
                                           v
|  The GSAKMP protocol specification defined an interpretation of the
   Logical Key Hierarchy (LKH) protocol as a rekey method.  [...]

It should say:
                                           v
|  The GSAKMP protocol specification defines an interpretation of the
   Logical Key Hierarchy (LKH) protocol as a rekey method.  [...]

(7)  improper term / wording

Sections B.5.6.1 and B.5.6.2, on page 25, talk about
[the reliability of] the "networks", where the text apparently
should talk about [the reliability of] the "transports"
(3 instances).

(8)  unneeded ASN.1 import

In the ASN.1 module of Section C.2, the IMPORTS clause on page 31
contains and unneeded object name and ID (perhaps copied-and-pasted
from other ASN.1 modules).
The lines,

     IMPORTS
       LifeDate
|        FROM PolicyToken {1.3.6.1.5.5.12.0.1}
|
|      KeyIdentifier
|        FROM PKIX1Implicit88 { iso(1) identified-organization(3)
|          dod(6) internet(1) security(5) mechanisms(5) pkix(7)
|          id-mod(0) id-pkix1-implicit(19) };

should be shortened to just say:

     IMPORTS
       LifeDate
|        FROM PolicyToken {1.3.6.1.5.5.12.0.1};

Please comment.

All but item (1) seems to be appropriate for an Errata Note.

Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.  But if you like, I can formally
submit an Errata Note on my own, with your consent.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+