Comments on draft-zorn-radius-keywrap-04.txt

["Nelson, David" <dnelson@enterasys.com>]

I think that the -04 revision is a substantial improvement over some earlier versions.  I do have some comments to offer, however.

On page 6, the definition of the App Id, KEK ID, and Key ID fields contain the sentence "Further specification o the content of this field is outside the scope of this document." Other than a basic description of the field, which includes a length and an expansion of the field name abbreviation, no substantive information is provided.  I think that some additional guidance on the uses and content of these fields needs to be included in the document, if there is to be any hope of creating multiple, independent interoperable implementations using the document alone as a reference.

On page 7, the length of the Nonce is specified to be 20 octets, while on page 8, the length of the Nonce is specified to be 32 octets.

On page 9, the definition of MAC Type indicates that two values are defined in this document, while four types are actually enumerated.

On page 9, the sentence "Further specification o the content of this field is outside the scope of this document." appears yet again.  I would echo my previous comments as to the required level of description in this document.

On page 11, the Implementation Notes indicate that the MAC field is to be considered as 16 octets of zero during the hash calculation.  On page 9, it says that the length of the MAC is algorithm dependent, being one of {16, 20, 32 or 64} octets in length.  Should the text on page 11 also reflect the differing possible lengths of the MAC, when zero-filling for the hash calculation?

Regards,
 
Dave
 
David B. Nelson
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330  
E-mail: dnelson@enterasys.com
 


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>