Subject: [karp] Karp Agenda 2: KeyStore?

From: Gregory Lebovitz <[email-masked]>
Date: Mon, 22 Mar 2010 14:11:27 -0700

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

---

From: Gregory Lebovitz <[email-masked]>
Date: Mon, 22 Mar 2010 14:38:39 -0700

On Mon, Mar 22, 2010 at 2:35 PM, Polk, William T. <[email-masked]>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" <[email-masked]> 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

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

---

From: "Polk, William T." <[email-masked]>
Date: Mon, 22 Mar 2010 17:35:23 -0400

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 think that maintaining them as separate documents is advisable, given their simplicity...

Thanks,

Tim

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:

Another question is:  "Do these documents serve better as stand-alone, or ought they be incorporated into the karp-framework document"

Thoughts?

Gregory.

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 22 Mar 2010 16:12:45 -0700

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.

Another comment is Session Acceptance diagram has a Key Id while the
Session Initiation does not.

Some things to think of are what needs to be done when both sides
initiate the connection at the same time. The document also does not
talk about how the short term keys are changed.

Thanks,
Vishwas

On Mon, Mar 22, 2010 at 2:38 PM, Gregory Lebovitz
<[email-masked]> wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>
>

---

From: Sean Turner <[email-masked]>
Date: Mon, 22 Mar 2010 18:25:54 -0700

In case there's discussion about the format for storing symmetric keys 
might I suggest: 
http://datatracker.ietf.org/doc/draft-ietf-keyprov-symmetrickeyformat/

spt

Polk, William T. wrote:
> 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 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:
>     Another question is:  "Do these documents serve better as
>     stand-alone, or ought they be incorporated into the karp-framework
>     document"
> 
>     Thoughts?
> 
>     Gregory.
> 
> 
> ------------------------------------------------------------------------
>

---

From: Gregory Lebovitz <[email-masked]>
Date: Mon, 22 Mar 2010 22:13:16 -0700

inline...

On Mon, Mar 22, 2010 at 7:31 PM, Polk, William T. <[email-masked]>wrote:

> Hi Vishwas,
>
> Comments inline...
>
> On 3/22/10 4:12 PM, "Vishwas Manral" <[email-masked]> wrote:
>
> > Gregory/ Tim,
> >
> 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.

> 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.
>
> >
> > 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
> 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:35 PM, Polk, William T. <
> [email-masked]>
> >> wrote:
> >>>
> >>> Gregory,
> >>>
> >>> did not suggest a presentation.  (We simply haven¹t received any
> suggestion
> presentation

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

---

From: "Polk, William T." <[email-masked]>
Date: Mon, 22 Mar 2010 22:31:32 -0400

Hi Vishwas,

Comments inline...

Glad to have a reader!

has been compromised before its expiration date.)  I suspect that would be a
manual process...

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

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
>>> did not suggest a presentation.  (We simply haven¹t received any suggestion

---

From: "Polk, William T." <[email-masked]>
Date: Tue, 23 Mar 2010 11:39:49 -0400

Responses inline...

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

> I think so. For purposes of quick response when a key has been compromised, an
> admin is terminated, a business relationship terminates, etc.
>  
> 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...

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

> 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