Database of Long-Lived Symmetric Cryptographic Keys
RFC 7210
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
(Sean Turner; former steering group member) Yes
(Stewart Bryant; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss, No Objection) No Objection
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.
(Barry Leiba; former steering group member) No Objection
Minor point: there's an obvious (to most) formatting problem in Section 2, "AdminKeyName", introduced in -08.
(Brian Haberman; former steering group member) No Objection
This draft contains the use of several 2119 keywords, yet does not contain the 2119 boilerplate or a reference to 2119.
(Jari Arkko; former steering group member) (was Discuss) No Objection
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.
(Joel Jaeggli; former steering group member) No Objection
Isn't it normal for the abstract to precede the boiler-plate?
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) (was Discuss) No Objection
(Richard Barnes; former steering group member) No Objection
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.
(Spencer Dawkins; former steering group member) No Objection
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?
(Stephen Farrell; former steering group member) (was Discuss) No Objection
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.
(Ted Lemon; former steering group member) No Objection