Re: [karp] Karp Agenda 2: KeyStore?

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

On 3/23/10 9:23 AM, "Vishwas Manral" <[e-mail]> wrote:

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

We are in absolute agreement.

>>> 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.
> 
I would appreciate any insight into the expected functionality.  I don't
have the routing clue to compile this list myself.

I suspect I will personally be more comfortable handling this in "glue
functions", but will reserve judgment until I see the list.

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

OK
> 
> 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
>>>> 
>>> 
>> 
>> 
>