Re: [karp] Karp Agenda 2: KeyStore?

["Polk, William T." <[e-mail]>]

Responses inline...

On 3/22/10 10:13 PM, "Gregory M. Lebovitz" <[e-mail]> wrote:

> inline...
> 
> On Mon, Mar 22, 2010 at 7:31 PM, Polk, William T. <[e-mail]>
> wrote:
>> Hi Vishwas,
>> 
>> Comments inline...
>> 
>> On 3/22/10 4:12 PM, "Vishwas Manral" <[e-mail]> 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.
> 
> I agree with this design "feature", that the RPD (routing protocol daemon)
> need not know or care how the keys were established. 
>  
>> 
>> Removing keys from the document isn't covered, though.  Should it be added?
> 
> I think so. For purposes of quick response when a key has been compromised, an
> admin is terminated, a business relationship terminates, etc.
>  
>> 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...
> 
> Agreed that we need this. The process could be manual to start (given the goal
> of incremental deployability), but I could envision an end state when a simple
> execution command at the router's command line interface kicks-off a fully
> automated process of generating, distributing and employing new keys.
> 

 
I can certainly add text, but note that all the reasons for removing keys
cited above (by either of us) are external to the system: terminating an
admin; severing a business relationship; deciding that a key is compromised.
These don't automate in my mind...


>> 
>>> 
>>> 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.
> 
> Might this leave us vulnerable to MitM run step-down attacks, i.e. to an old
> key (assuming said key was not properly discarded in a timely fashion)?
>  
>> 
>> 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.
> 
> Could be so. Or it could be a function of a KMP, one that is keeping the key
> life times and thus knowing when it's time to kick off the negotiation of a
> new security association, then install it for use.
>  


Here we disagree.

I think the routing protocol needs to be in control here.  Otherwise, the
keytable needs to track processes, traffic levels, etc.  It is much better
for the routing protocol process to track this information.


>> 
>> 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.
> 
> I think there needs to be both:  the Routing Protocol needs to be able to
> change keys during an existing session, and some function needs to exist by
> which to tell the routing protocol that it's time to do so, then the various
> parameters needed for that new key usage need to be available to the Routing
> Protocol. 


Having an interface to force the routing protocol to change keys may be
reasonable, but it is not (imho) a function of the keytable.  It is going to
be initiated based on some external event (e.g., severing a business
relationship), and needs to follow some manual adjustments to the keytable
(e.g., deleting unexpired keys associated with peers that are no longer
trusted).  A person needs to be involved, so the signal to force a key
change could be directed to the routing protocol instantiation, which would
then request a new key in the usual fashion.  This doesn't change the
result, of course, but it avoids overloading the keytable concept.

>             In the framework we have this covered by:
>  - KeyStore - the place where the security association parameters go, so that
> the Routing Protocol knows how/where to look for the info
>  - The three API's, so that the KMP and the RoutingPRotocol can notify each
> other that there is new security association material ready, or needed.
>  - KMP
> 
> -Gregory
>  
>> 
>> 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
>>> <[e-mail]> wrote:
>>>> 
>>>> 
>>>> On Mon, Mar 22, 2010 at 2:35 PM, Polk, William T. <[e-mail]>
>>>> 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" <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/karp
>>>> 
>>>> 
>>> 
>> 
> 
>