Database of Long-Lived Symmetric Cryptographic Keys
draft-ietf-karp-crypto-key-table-10

[Ballot comment]
I think the Section 3 text about IPsec and its PAD is still not clear enough that *that* table has nothing to do with the table definition in *this* document.

I would like to talk with the authors/WG about why FCFS is the appropriate policy for the KDFs and algorithm identifiers. Can someone tell me the rationale that the WG used when this was decided? FWIW, I am very supportive of relatively open IANA policies, but I want to understand why they make sense here.

[Ballot comment]
Thank you for working on my Discuss and Comments.

My Discuss used to read...

> I am entering a short Discuss since my attempts to discuss this point
> by email have not produced a result.
>
> - Is this document intended to establish a registry for secure routing
>  protocols or for all security protocols?
> - If general-purpose, how is this a legitimate product of the KARP
>  working group?
> - If specific to routing protocols how is this language in the
>  document consistent with that claim?
> - Why is the registry populated only with 802.1X?
>
> Essentially, and bluntly, please convince me that you are not using
> the KARP working group as a way of introducing a registry (that may or
> may not have value) that is not used by KARP but has some other
> unstated purpose.

I was pretty sure we had this agreed, and I see that 802.1X has gone
from the text, which is good because I don't believe it is used in
routing security at this time. Just to note that 802.1X still shows as
a reference, so you need to clean that up.

However, I see that you have introduced some new references to pre-
populate the registries.
                                 
RFC 2104 for HMAC-SHA-1
RFC 2104 for HMAC-SHA-1-96
RFC 4493 for AES-128-CMAC
RFC 5926 for AES-128-CMAC-96

Some observations:
- These initial population values are barely mentioned in the document.
  They do appear as examples in the description of the conceptual table,
  but there is no reference to routing security either through state of
  the art or work in progress.
- A quick search for (random example) RFC 4493 shows that it is cited
  by precisely one non-expired routing document.
- Perhaps the main point of AES-128-CMAC will come through RFC 5926 and
  the recommended use of TCP/AO to secure TCP-based routing protocols.

My conclusion is that you *are* pre-populating this table with
reasonable values, but that you are not doing the work to justify why
you are adding these values.

Having satisfied myself that the values are relevant, I don't require
that you do additional work. But I think it would not be hard or a bad
idea to add a short section titled "Initial Table Population" that lists
the initial values and explains why they are there.

[Ballot comment]

Thanks for resolving my discuss.

I've left the comments below but didn't check if there's
more to say or do about 'em. Feel free to ping me if
there is,

S.

--- these were discusses but are now comments

(1) What'd happen if I merge two databases (e.g. if I
buy some new bigger kit that replaces multiple devices)
and the admin key name collides? Should you add a
key-table-name property that should be selected so as
to avoid collisions?

Sam said:

>> I think you'd want to define how to handle this when defining the merge
>> operation.
>> I can see two approaches that seem likely.
>> First, for environments where the admin key name is not stored in
>> external management systems, just change the name.
>> For systems where an external management system needs to know the admin
>> key name reject the merge until conflicts are resolved (or perform the
>> merge in the external management system).
>>
>> I don't think a key table name would be helpful and it would be
>> confusing as an operator.  If anything I'd expect protocol to partition
>> the table.
>>
>> I've been an operator in situations like you describe and with this
>> style of database I'd prefer to resolve the conflicts than to have yet
>> another database partition.  It's not just lazyness that causes me to
>> think adding the field you propose is the wrong approach; I think it
>> would not add value for the use cases I can see.

I think adding a bit of text about that would be good.

(2) section 2: Having registries for KDFs and AlgIDs
here seems wrong, or maybe I'm confused. Either the
protocol that uses the DB will specify the KDF and
AlgIDs or it will not. If it does, then any such
registry will be part of the protocol itself. If it
does not, then I don't see how I get interop without
having a specificaiton for the input bits to the KDF,
etc which are not always obvious and are not specified
here. Either way, the KDF registry here seems useless
given that there's a registry for the Protocol field.
What am I missing? 

Following mail discussion, I'm ok with that but
have a suggestion:

I think it'd be good to note that there are likely to
be registry entries that overlap with other protocol's
registries. Perhaps it'd be useful to have a column
in this registry that also notes which other protocol(s)
define code points for the entries in this one?



--- original comments below

- section 2: AdminKeyName "by humans" seems wrong, I
think you mean "for humans". The last sentence in this
definition also hides a uniqueness requirement. I agree
with Pete's discuss on i18n here.

- section 2: Is there a bug in the cardinality of
PeerKeyName vs. Peers? It reads as if I can have e.g. 3
Peers for a unicast case and each of those can have
their own local key name, but yet I can only store one
peer key name.

- section 4: this seems a bit vague to me fwiw, I
wondered if someone has actually tried this with a real
key management protocol? (E.g. see my discuss points
about KDFs above)

- Should you say something (e.g. in sections 1 or 7)
about keys that are stored in a HSM? I guess this spec
is really not for those.

[Ballot discuss]


(3) section 2: Direction - How would you support a key
with "both" here but that is used with a KDF and
direction-specific KDF inputs? I thought some of the
NIST KDFs might have that property when used in
protocols.

[Ballot comment]

--- these were discusses but are now comments

(1) What'd happen if I merge two databases (e.g. if I
buy some new bigger kit that replaces multiple devices)
and the admin key name collides? Should you add a
key-table-name property that should be selected so as
to avoid collisions?

Sam said:

>> I think you'd want to define how to handle this when defining the merge
>> operation.
>> I can see two approaches that seem likely.
>> First, for environments where the admin key name is not stored in
>> external management systems, just change the name.
>> For systems where an external management system needs to know the admin
>> key name reject the merge until conflicts are resolved (or perform the
>> merge in the external management system).
>>
>> I don't think a key table name would be helpful and it would be
>> confusing as an operator.  If anything I'd expect protocol to partition
>> the table.
>>
>> I've been an operator in situations like you describe and with this
>> style of database I'd prefer to resolve the conflicts than to have yet
>> another database partition.  It's not just lazyness that causes me to
>> think adding the field you propose is the wrong approach; I think it
>> would not add value for the use cases I can see.

I think adding a bit of text about that would be good.

(2) section 2: Having registries for KDFs and AlgIDs
here seems wrong, or maybe I'm confused. Either the
protocol that uses the DB will specify the KDF and
AlgIDs or it will not. If it does, then any such
registry will be part of the protocol itself. If it
does not, then I don't see how I get interop without
having a specificaiton for the input bits to the KDF,
etc which are not always obvious and are not specified
here. Either way, the KDF registry here seems useless
given that there's a registry for the Protocol field.
What am I missing? 

Following mail discussion, I'm ok with that but
have a suggestion:

I think it'd be good to note that there are likely to
be registry entries that overlap with other protocol's
registries. Perhaps it'd be useful to have a column
in this registry that also notes which other protocol(s)
define code points for the entries in this one?



--- original comments below

- section 2: AdminKeyName "by humans" seems wrong, I
think you mean "for humans". The last sentence in this
definition also hides a uniqueness requirement. I agree
with Pete's discuss on i18n here.

- section 2: Is there a bug in the cardinality of
PeerKeyName vs. Peers? It reads as if I can have e.g. 3
Peers for a unicast case and each of those can have
their own local key name, but yet I can only store one
peer key name.

- section 4: this seems a bit vague to me fwiw, I
wondered if someone has actually tried this with a real
key management protocol? (E.g. see my discuss points
about KDFs above)

- Should you say something (e.g. in sections 1 or 7)
about keys that are stored in a HSM? I guess this spec
is really not for those.

[Ballot discuss]
I am entering a short Discuss since my attempts to discuss this point by email have not produced a result.

- Is this document intended to establish a registry for secure routing protocols or for all security protocols?
- If general-purpose, how is this a legitimate product of the KARP working group?
- If specific to routing protocols how is this language in the document consistent with that claim?
- Why is the registry populated only with 802.1X?

Essentially, and bluntly, please convince me that you are not using the KARP working group as a way of introducing a registry (that may or may not have value) that is not use by KARP but has some other unstated purpose.

[Ballot comment]
Support Pete's DISCUSS on this. 

It feels like this document is kind of trying to define a syntax, without actually doing it.  It would make things a lot clearer if you could actually define a concrete syntax, at least at the level of fields. 

Also the AdminKeyName definition is mangled.

[Ballot discuss]

Sorry to add to the DISCUSS points on this. I do think
this will be a useful specification in the end and is a
fine piece of work that's almost there - hopefully
my questions here will be easily resolved.

(1) What'd happen if I merge two databases (e.g. if I
buy some new bigger kit that replaces multiple devices)
and the admin key name collides? Should you add a
key-table-name property that should be selected so as
to avoid collisions?

(2) section 2: Having registries for KDFs and AlgIDs
here seems wrong, or maybe I'm confused. Either the
protocol that uses the DB will specify the KDF and
AlgIDs or it will not. If it does, then any such
registry will be part of the protocol itself. If it
does not, then I don't see how I get interop without
having a specificaiton for the input bits to the KDF,
etc which are not always obvious and are not specified
here. Either way, the KDF registry here seems useless
given that there's a registry for the Protocol field.
What am I missing? 

(3) section 2: Direction - How would you support a key
with "both" here but that is used with a KDF and
direction-specific KDF inputs? I thought some of the
NIST KDFs might have that property when used in
protocols.

[Ballot comment]

- section 2: AdminKeyName "by humans" seems wrong, I
think you mean "for humans". The last sentence in this
definition also hides a uniqueness requirement. I agree
with Pete's discuss on i18n here.

- section 2: Is there a bug in the cardinality of
PeerKeyName vs. Peers? It reads as if I can have e.g. 3
Peers for a unicast case and each of those can have
their own local key name, but yet I can only store one
peer key name.

- section 4: this seems a bit vague to me fwiw, I
wondered if someone has actually tried this with a real
key management protocol? (E.g. see my discuss points
about KDFs above)

- Should you say something (e.g. in sections 1 or 7)
about keys that are stored in a HSM? I guess this spec
is really not for those.

[Ballot discuss]
Thanks for writing this useful document. I support this work, and will gladly recommend its approval.

However, there is one issue that I would like to understand first about the scope of the document and the proposed database's interaction with possible other databases in the same system.

In particular, I would like to understand if the proposed database has some relationship to the IPsec PAD. For instance, if I had a box that had both IPsec and the proposed database, would there be some interaction or could information in the new database be used also for protocols such as IPsec?

Or is the scope of the document related only to routing protocol applications (which might not use IPsec at all)?

[Ballot comment]
I would like to talk with the authors/WG about why FCFS is the appropriate policy for the KDFs and algorithm identifiers. Can someone tell me the rationale that the WG used when this was decided? FWIW, I am very supportive of relatively open IANA policies, but I want to understand why they make sense here.

[Ballot discuss]
I hope this is a very short-lived DISCUSS.

You never define "string" in section 2, but you do say:

  To accommodate manual key management, the format of the fields has
  been purposefully chosen to allow updates with a plain text editor
  and to provide equivalent display on multiple systems.

That reads to me like maybe these things are expected to be US-ASCII. But then you say:

  The AdminKeyName field contains a string identifying
  the key by humans.
 
(Side comment: That's worded really badly. I think you mean "The AdminKeyName field contains a human-readable string meant to identify the key for the user." Or something like that.)

Do you intend the AdminKeyName to be internationalizable? If so, then here or 5.1 needs something more:

  5.1 Key Names

  When a key for a given protocol is identified by an integer key
  identifier, the associated key name will be represented as lower case
  hexadecimal integers with the most significant octet first.  This
  integer is padded with leading 0's until the width of the key
  identifier field in the protocol is reached.
 
What if they are *not* identified by an integer? (Can that happen?) In that case, do you want them to be Unicode characters? In some particular format? The requirement that they be editable by a "plain text editor" doesn't quite make it clear what you mean.

Something additional is needed.

[Ballot discuss]
I would like to talk with the authors/WG about why FCFS is the appropriate policy for the KDFs and algorithm identifiers.

Also, I echo the question posed by David Black in his Gen-ART review of the relationship of this database to the IPsec PAD and other databases.

[Ballot comment]
I have no objection to the publication of this document as it stands,
but it is not clear to me why this document, coming out of KARP, only
populates the IANA registry with one value for a non-IP and non-routing
protocol.  Surely KARP could have seeded the registry more richly, and
surely the document could have discussed the relevance of IEEE 802.1X.
I suppose this is intended to be covered by the charter work item
- Define one or more frameworks describing the common elements for
  modern authentication in routing protocols.
but the discussion of routing protocols in this document seems at best
peripheral.



I would also appreciate you looking at the points below to see whether
they are issues, and fixing them if necessary.

---

I struggled with the term "security protocol".

Section 1 has:
  Security protocols such as TCP-AO [RFC5925]

But I also see:
  security protocols such as cryptographic
  authentication for routing protocols.

I think that you are defining "security protocol" to be "any protocol
where messages are exchanged in a secure way." Is that so? Would it be
possible (whether I am right or not) to include a clearer definition
for the reader?

---

Section 2

      Interfaces
        The Interfaces field identifies the set of physical and/or
        virtual interfaces for which it is appropriate to use this key.
        When the long-lived value in the Key field is intended for use
        on any interface, this field is set to "all".

Do you mean that it is set to the value "all" or is it set to a local,
implementation-dependent value that indicates "all interfaces"?

---

Section 8.1.1 lists three things that the registry must include:

      - Protocol Name (unique within the registry);
      - Specification; and
      - Protocol Specific Info.

Section 8.1.2 shows the registry with three columns:

      Protocol            Protocol Specific Info    Reference

While I can assume the mapping between these, perhaps they should be
consistent?

[Ballot comment]
One question - in 3. Key Selection and Rollover

      (3)  If an interface is specified, the Interfaces field includes I
      or "all";

This sentence didn't parse for me. Is s/specified, the/specified and the/ what's meant?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-karp-crypto-key-table-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, a new registry is to be created called the "KeyTable Protocols" registry. The registry is to be maintained through Specification Required as defined in RFC 5226.

Therre are initial values in the registry as follows:

------------------------------------------------------------------------
Protocol Name | Specification | Protocol Specific Values
------------------------------------------------------------------------
IEEE 802.1X CAK IEEE Std 802.1X-2010, A Key Management Domain (KMD).
"IEEE Standard for Local A string of up to 253 UTF-8
and Metropolitan Area characters that names the
Networks -- Port-Based transmitting authenticator's
Network Access Control". key management domain.

A Network Identifier (NID).
A string of up to 100 UTF-8
characters that identifies
a network service. The NID
can also be null, indicating
the key is associated with
a default service.
----------------------------------------------------------------------

Second, a new registry will be created called the "KeyTable KDFs" registry. The registry is to be maintained through First Come First Served as defined in RFC 5226.

There are no initial values in the new registry.

Third, a new registry will be created called the "KeyTable AlgIDs" registry. The registry is to be maintained through First Come First Served as defined in RFC 5226.

There are no initial values in the new registry.

IANA understands that these are the only actions required to be completed by IANA upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Database of Long-Lived Symmetric Cryptographic Keys) to Proposed Standard


The IESG has received a request from the Keying and Authentication for
Routing Protocols WG (karp) to consider the following document:
- 'Database of Long-Lived Symmetric Cryptographic Keys'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-04-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies the information contained in a conceptual
  database of long-lived cryptographic keys used by many different
  security protocols.  The database is designed to support both manual
  and automated key management.  In addition to describing the schema
  for the database, this document describes the operations that can be
  performed on the database as well as the requirements for the
  security protocols that wish to use the database.  In many typical
  scenarios, the security protocols do not directly use the long-lived
  key, but rather a key derivation function is used to derive a short-
  lived key from a long-lived key.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/ballot/


No IPR declarations have been submitted directly on this I-D.