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-ietf(_at_)mit(_dot_)edu]
Sent: Wednesday, August 14, 2013 3:32 PM
To: Black, David
Cc: housley(_at_)vigilsec(_dot_)com; tim(_dot_)polk(_at_)nist(_dot_)gov;
Dacheng Zhang
(zhangdacheng(_at_)huawei(_dot_)com); General Area Review Team
(gen-art(_at_)ietf(_dot_)org);
karp(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08
"Black," == Black, David <david(_dot_)black(_at_)emc(_dot_)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.