RFC Errata
Found 11 records.
Status: Verified (1)
RFC 4534, "Group Security Policy Token v1", June 2006
Source of RFC: msec (sec)
Errata ID: 940
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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)
RFC 4534, "Group Security Policy Token v1", June 2006
Source of RFC: msec (sec)
Errata ID: 942
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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]. [..]