errata logo graphic

Found 11 records.

Status: Verified (1)

RFC4534, "Group Security Policy Token v1", June 2006

Source of RFC: msec (sec)

Errata ID: 940

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Verifier Name: Tim Polk
Date Verified: 2008-11-20

Section B.4 says:

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 between 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.

Notes:

from pending


Status: Held for Document Update (10)

RFC4534, "Group Security Policy Token v1", June 2006

Source of RFC: msec (sec)

Errata ID: 942

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Sean Turner
Date Held: 2010-08-14

Section B.5.7 says:

On page 26, defines:

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

It should say:

Add the following clarification immediately after the ASN.1:

The OCTET STRING in each of these is an opaque blob whose
processing is subsequently defined in the vendor or domain-specific types.

Notes:

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!


Errata ID: 2351

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Sean Turner
Date Held: 2010-08-14

Section B.5.4 says:

On page 24, defines:

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

It should say:

Add the following clarification immediately after the ASN.1:

The OCTET STRING in each of these is an opaque blob whose
processing is subsequently defined in the vendor or domain-specific types.

Notes:

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!


Errata ID: 2352

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Sean Turner
Date Held: 2010-08-14

Section B.5.6 says:

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).

It should say:

Add the following clarification immediately after last paragraph:

The OCTET STRING in each of these is an opaque blob whose
processing is subsequently defined in the vendor or domain-specific types.

Notes:

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!


Errata ID: 2371

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

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).

Errata ID: 2372

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section C.2 says:

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

The current text is:

     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) };


It should say:

This text should be shortened to just say:

     IMPORTS
       LifeDate
|        FROM PolicyToken {1.3.6.1.5.5.12.0.1};


Errata ID: 64

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

There are three terminology issues

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. ...
  "

Notes:

from pending


Errata ID: 2368

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

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.

It should say:

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.

Errata ID: 2370

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 


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:

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

Errata ID: 2369

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

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:

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

Errata ID: 2367

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20

 

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:

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].  [..]

Report New Errata