Sam, Thanks for taking another look at this. I think we're in good shape on the IPsec relationship concern, but I think key selection responsibility could use some more attention.
[A] The new text on the IPsec relationship looks good - I'd suggest also adding a sentence to state that keys for IPsec pre-shared-key authentication are not appropriate for this key database. [C] The key selection responsibility was not clear to me from the draft - the intent/design stated in your message is fine (and having one key be returned is simpler, and probably more robust than handing multiple keys to different protocol implementations and hoping that they do something consistent): > I think we've discussed key selection in the WG and come to a different > conclusion. The key table selects the key. We expect peer, key ID, > protocol and interface to identify a unique key for an inbound packet. My confusion stems from section 3 starting out by stating that the key database is consulted "to find the key to use on an outgoing message" followed by several sentences that indicate that the consultation may result in multiple keys. That leads to a suggestion and a question. Suggestion: Add a new paragraph at the start of Section 3 to make the functional responsibility clear: Key selection is the responsibility of the key database functionality; in all cases, the protocol requests a key, and the database returns one key or an indication that there is no matching key. When multiple keys match a protocol's request, the key database selects one as described further in this section. Question: What happens, when despite all the measures described in Section 3, multiple keys match a protocol's request? How does one ensure that the key databases at both ends of the security association return the same key? Thanks, --David > -----Original Message----- > From: Sam Hartman [mailto:hartmans-i...@mit.edu] > Sent: Wednesday, August 14, 2013 3:32 PM > To: Black, David > Cc: hous...@vigilsec.com; tim.p...@nist.gov; Dacheng Zhang > (zhangdach...@huawei.com); General Area Review Team (gen-art@ietf.org); > k...@ietf.org; i...@ietf.org > Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08 > > >>>>> "Black," == Black, David <david.bl...@emc.com> writes: > > > Black,> [A] Overall - I would like to see a paragraph added on how > Black,> this database conceptually relates to the IPsec Peer > Black,> Authorization Database (PAD) - see RFC 4301, section 4.4.3. > > It doesn't. > not even a little bit. > It's not IPsec; it's not about what key management peers to interact > with. > > It's conceptually similar to the Security Association Database (SAD). > In a discussion with Jari I agreed to propose text for a paragraph > describing how this interacts with IPsec. > > If this conceptual database is used to manage to keys for a security > protocol that uses IPsec [RFC4301] security services, then the > interactions between this conceptual database and the IPsec > databases needs to be described by the protocol specification. > Typically such a protocol would insert entries into the Security > Association Database (SAD) when rows are inserted into the key table > and remove SAD entries when key table rows are removed. The > protocol specification needs to describe how the SAD entries are > constructed along with any other IPsec database entries that are > needed, including a description of how these entries are ordered > along with other IPsec database entries. The question of whether it > is desirable to use this conceptual database to manage protocols > that use IPsec security services is open and has not been evaluated. > > Black,> [C] (Section 3) Where does key selection occur? I would > Black,> suggest that the database return all possible keys and let > Black,> the protocol figure out what to use. This is particularly > Black,> important for inbound traffic for obvious reasons. > > I think we've discussed key selection in the WG and come to a different > conclusion. The key table selects the key. We expect peer, key ID, > protocol and interface to identify a unique key for an inbound packet. > > So, I think the concern you raise is not a problem. > While there was not a specific thread discussing key selection or this > issue, there were multiple reviewers who provided comments on key > selection over the development of the document, and making a major > change at this point without a technical problem seems undesirable. > If I'm missing something and the inbound packet issue is a problem then > we need to discuss it. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
