Re: [karp] Karp Agenda 2: KeyStore?

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

On 3/22/10 10:30 PM, "Vishwas Manral" <[e-mail]> wrote:

> Hi Tim/ Greg,
> 
> I mostly agree with Greg.
> 
> On Mon, Mar 22, 2010 at 10:13 PM, Gregory 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.
> RPD never does bother. However based on how the Key is derived we can
> determite the security aspects of the protocol authentication
> mechanism.

I'm not sure I buy this.  I don't believe it matters whether the key is
derived by an automated key management system, or shared through an out of
band mechanism.  If the key is in the table, that means it is appropriate
for use.

Perhaps I am missing something, though.  What security aspects were you
thinking of?

> 
>>> 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.
> I agree.
> 
>>> 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.
> Agree again, though I still need to look at the Housely draft.
> 
>>>> 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)?
> I did not understand how MITM would be an issue here? Could you explain?
> 

I am with you on this one.  As I said above, if the key is in the table, it
is acceptable for use.  If the key was not properly discarded (by *either*
peer), that is a operational failure that is not going to be overcome by
asserting KeyIDs.  It would also mean that the routing protocol had to
maintain a list of all the keys it can use (by ID).  This is a nightmare,
since we need to keep the keytable and the routing protocol's keyid table
synchronized.  Let's not go there.

>>> 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.
> May be there is a generic set of functions required for all routing
> and signalling protocols (let us not preclude LDP, RSVP-TE, CR-LDP,
> LMP and others from the discussion) which is independent of the
> Routing protocol itself is how it finally will be.
> 

Perhaps, but are they really functions of the keytable?

>>> 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.
> That is interesting. So the assumption from your draft is the sender
> and receiver keys can be seperate and if the protocol wants the same
> in case I have mentioned they can probably drop one of the Keys. Is my
> understanding correct?
> 

Pretty close... The keytable draft could support protocols that routinely
use different session keys in different directions, or protocols that use a
single session key for traffic in both directions.  If the protocol demands
a single uni-directional traffic key, and two keys have been simultaneously
derived during simultaneous open, you either have to discard one key *or*
discard both and start over.

I can see that we need more text in this area...

Thanks,

Tim

> Thanks,
> Vishwas
> 
> ssion 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,
>>>> 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
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> ----
>> IETF related email from
>> Gregory M. Lebovitz
>> Juniper Networks
>> 
>