Re: [karp] Karp Agenda 2: KeyStore?

Hi Vishwas,

Comments inline...

On 3/22/10 4:12 PM, "Vishwas Manral" <vishwas.ietf@gmail.com> wrote:

> Gregory/ Tim,
> 
> I agree with Gregory regarding having the presentation at the KARP meeting.
> 
> I scanned through the Polk draft. One comment is that the Long lived
> Crypto Keys stillneed to be changed manually.

Glad to have a reader!

Actually, the Long Lived Keys can be established manually *or* through an
Automated Key Management Protocol.  (See Figure 1 in
draft-polk-saag-rtg-auth-keytable-02).  This is a key concept for our draft
- the routing protocol need not know (or care) how long lived keys were
established.  This allows incremental introduction of automated key
management techniques seamlessly.

Removing keys from the document isn't covered, though.  Should it be added?
Expiration of entries is covered in draft-housley-saag-crypto-key-table-00,
but perhaps we need to discuss removal for other circumstances.  (I'm
thinking of severing a business relationship, or deciding a long lived key
has been compromised before its expiration date.)  I suspect that would be a
manual process...

> 
> Another comment is Session Acceptance diagram has a Key Id while the
> Session Initiation does not.

In our model, a session initiator is not concerned which long-lived key they
get, only that the key is shared with the right peer(s) and intended for use
with the right protocol.  So, the initiator's request for a key does not
contain a KeyID.

When a peer accepts a session, the initiator has already selected a
long-lived key.  The KeyID is essential in this case, or the peer will not
derive the right session key.

> 
> Some things to think of are what needs to be done when both sides
> initiate the connection at the same time.

Won't different protocols handle this differently?  I could envision ending
up with two parallel (but authenticated) sessions, or the protocol could
attempt to resolve this into a single connection by selecting one peer as
the "initiator" and discard the session key material from the aborted
session.

>                                           The document also does not
> talk about how the short term keys are changed.

The keytable does not force any key changes - it just lies there.
Generation of short term keys is entirely under the routing protocol's
control.

First and foremost, a new session means a new short term key. That may be
enough for some protocols.  For protocols with long-lived sessions, the
routing protocol can incorporate protocol specific mechanisms for changing
session keys during an existing session.

If these protocol specific mechanisms are designed such that the new session
keys are derived from different long lived keys, the peer initiating the
transition requests new keys just as if it was initiating a new session.
The other peer would behave as if it was accepting a new session...

We could add some text here if you would like.  (I think a brief reference
to tcp-ao's mechanism for changing keys during sessions is all we have now.)

Thanks,

Tim
> 
> Thanks,
> Vishwas
> 
> On Mon, Mar 22, 2010 at 2:38 PM, Gregory Lebovitz
> <gregory.ietf@gmail.com> wrote:
>> 
>> 
>> On Mon, Mar 22, 2010 at 2:35 PM, Polk, William T. <william.polk@nist.gov>
>> wrote:
>>> 
>>> Gregory,
>>> 
>>> There has really been no change to those documents since Hiroshima, so I
>>> did not suggest a presentation.  (We simply haven¹t received any suggestion
>>> to change them.)  I do have karp on my schedule and will be in the room.
>> 
>> I'll leave it to the chairs to decide. Since the last preso was a BoF, it
>> may make sense to do it again, if only to push people to read and review and
>> provide input.
>> 
>>> 
>>> I think that maintaining them as separate documents is advisable, given
>>> their simplicity...
>> 
>> If there is applicability outside of karp-framework, then I agree. If the
>> applicability is only w/in the karp-framework, then I'd suggest we suck it
>> into the "KeyStore" section of that document. But I haven't thought too much
>> about it until just now, sitting here with Bill Atwood, working on slides
>> and open issues / open sections.
>> Bill will have this as an open question on his slides and we can discuss in
>> WG. WFY?
>> Gregory
>> 
>>> 
>>> Thanks,
>>> 
>>> Tim
>>> 
>>> 
>>> On 3/22/10 2:11 PM, "Gregory M. Lebovitz" <gregory.ietf@gmail.com> wrote:
>>> 
>>> KARPies, Tim & Russ,
>>> I notice that the current agenda for KARP does NOT include a presentation
>>> by Tim/Russ on their documents that defines in more detail what
>>> draft-ietf-karp-framework calls the KeyStore. I'm thinking that would be a
>>> good thing to have presented again (it was presented at the BoF already
>>> once), because we need to decide if these become WG documents, or how to
>>> proceed them.
>>> 
>>> Those documents are:
>>> draft-housley-saag-crypto-key-table-01
>>> draft-polk-saag-rtg-auth-keytable-02
>>> 
>>> Another question is:  "Do these documents serve better as stand-alone, or
>>> ought they be incorporated into the karp-framework document"
>>> 
>>> Thoughts?
>>> 
>>> Gregory.
>> 
>> 
>> 
>> --
>> ----
>> IETF related email from
>> Gregory M. Lebovitz
>> Juniper Networks
>> 
>> _______________________________________________
>> karp mailing list
>> karp@ietf.org
>> https://www.ietf.org/mailman/listinfo/karp
>> 
>> 
> 