Subject: [karp] FWD from Tero Kivinen: Some comments to draft-ietf-karp-crypto-table

From: Tero Kivinen <[email-masked]>
Date: Wed, 28 Mar 2012 14:12:24 +0300

Better forward this to list too, as I am not sure who is on the
[email-masked] list...

Subject: Some comments to draft-ietf-karp-crypto-table
From: Tero Kivinen <[email-masked]>
To: [email-masked]
Date: Sat, 24 Mar 2012 19:55:12 +0200

In section 2. Conceptual Database Structure the document says:

   To accommodate manual key management, then formatting of the fields
   has been purposefully chosen to allow updates with a plain text
   editor.

but there is ProtocolSpecificInfo which is specified to be:

         The ProtocolSpecificInfo field contains a variable length
         binary object with any protocol specific values.

which as binary object might not be that easy to edit with plain text
editor.

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

      PeerKeyID
         For pairwise keys, the PeerKeyID field is a 16 bit integer in
         hexadecimal provided by the peer.  If the peer has not yet
         provided this value, the PeerKeyID is set to "unknown".  For
         group keying, the PeerKeyID field is set to "group", which
         easily accommodates group keys generated by a third party.  If
         the protocol associated wit this key uses a keyname instead of
				 ^^^

Typo.

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

      Protocol
         The Protocol field identifies a single security protocol where
         this key may be used to provide cryptographic protection. This
         protocol establishes a registry for this field; the registry
	 ^^^^^^^^

I think this should be document, not protocol.

         also specifies the contents of the following field,
         ProtcolSpecificInfo, for each registered protocol.

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

SendNotBefore, SendNotAfter, RcvNotBefore, RcvNotAfter seem to have
lots of errors, I assume those are leftover from the text before when
it was only NotBefore and NotAfter:

      SendNotBefore
         The NotBefore field specifies the earliest date and time in
	     ^^^^^^^^^

SendNotBefore

         Universal Coordinated Time (UTC) at which this key should be
         considered for use when sending traffic.  The format is
         YYYYMMDDHHSSZ, where four digits specify the year, two digits
         specify the month, two digits specify the day, two digits
         specify the hour, and two digits specify the minute.  The "Z"
         is included as a clear indication that the time is in UTC.

I think it should also specify what SS means for, even when it is
quite obvious...

      SendNotAfter
         The NotAfter field specifies the latest date and time at which
	     ^^^^^^^^

SendNotAfter

         this key should be considered for use when sending traffic.
         The format is the same as the NotBefore field.
				       ^^^^^^^^^

SendNotBefore

      RcvNotBefore
         The NotBefore field specifies the earliest date and time in
	     ^^^^^^^^^

RcvNotBefore, and I do not think there is need to repeat the format,
jut point to SendNotBefore.

         Universal Coordinated Time (UTC) at which this key should be
         considered for use when processing received traffic.  The
         format is YYYYMMDDHHSSZ, where four digits specify the year,
         two digits specify the month, two digits specify the day, two
         digits specify the hour, and two digits specify the minute.
         The "Z" is included as a clear indication that the time is in
         UTC.

      RcvNotAfter
         The NotAfter field specifies the latest date and time at which
	     ^^^^^^^^

RcvNotAfter

         this key should be considered for use when processing received
         traffic.  The format is the same as the NotBefore field.
						 ^^^^^^^^^

SendNotBefore

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

In the section 3 there is again issues with NotBefore/NotAfter vs
SendNotBefore/SendNotAfter/RcvNotBefore/RcvNotAfter.

      (6)  NotBefore <= T <= NotAfter.

This should be

      (6)  SendNotBefore <= T <= SendNotAfter.

(2 places). 

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

   In addition, multiple entries with overlapping use periods are
   expected to be employed to provide orderly key rollover.  In these
   cases, the expectation is that systems will transition to the newest
   key available.  To meet this requirement, this specification
   recommends supplementing the key selection algorithm with the
   following differentiation: select the long-lived key specifying the
   most recent time in the NotBefore field.
			   ^^^^^^^^^

SendNotBefore.

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

      (5)  NotBefore <= T <= NotAfter.

   Note that the key usage is loosely bound by the times specified in
   the NotBefore and NotAfter fields.

should be 

      (5)  RcvNotBefore <= T <= RcvNotAfter.

   Note that the key usage is loosely bound by the times specified in
   the RcvNotBefore and RcvNotAfter fields.

and

      (6)  NotBefore <= T <= NotAfter.

should be

      (6)  RcvNotBefore <= T <= RcvNotAfter.

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

In section 4. Operational Considerations the 1st paragraph

   If usage periods for long-lived keys do not overlap and system clocks
   are inconsistent, it is possible to construct scenarios where systems
   cannot agree upon a long-lived key.  When installing a series of keys
   to be used one after the other (sometimes called a key chain),
   operators should configure the NotAfter field of the preceding key to
   be several days after the NotBefore field of the subsequent key to
   ensure that clock skew is not a concern.

should point out that you can make so that receiving ends q
RcvNotAfter is larger than other ends SendNotAfter and that new key
has RecvNotBefore that is earlier than other peers SendNotBefore.

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

In this draft (and quite a lot of other drafts I have been reading
lately), it has been very annoying when people use references to RFCs
as nouns, and expect everybody to remember what RFC is what:

   It is recognized in [RFC4107] that automated key management is not
   viable in some situations.  The conceptual database specified in this

It would be much nicer to read text which said:

   It is recognized in Guidelines for Cryptographic Key Management
   ([RFC4107]) that automated key management is not viable in some
   situations. The conceptual database specified in this
-- 
[email-masked]