Re: [karp] Karp Agenda 2: KeyStore?

[Vishwas Manral <[e-mail]>]

Hi Tim,

I guess we are in near unision now.
> 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?
Well if the long term key is not a secure, the short term keys would
not be either. So it does matter how secure the Long term keys are.

>> 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?
A routing protocol expects a certain set of functionality. The Key
table provides another. We could either incorporate the same in the
KeyTable or have it in some "Glue functions" which can be defined
seperately.

> 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...
Sounds correct.

Thanks,
Vishwas

On Tue, Mar 23, 2010 at 9:03 AM, Polk, William T. <[e-mail]> wrote:
>
> 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
>>>
>>
>
>