Re: [karp] Karp Agenda 2: KeyStore?

[Gregory Lebovitz <[e-mail]>]

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.


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


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


-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks