Subject: Re: [karp] Please take a look at draft-hartman-karp-ops-model-00.txt

From: Sam Hartman <[email-masked]>
Date: Tue, 31 Aug 2010 14:53:35 -0400

>>>>> "Gregory" == Gregory Lebovitz <[email-masked]> writes:

Hi. Thanks for a really great review.

    Gregory> Hey Sam and Dacheng,
    Gregory> Here is a review of the ops-model document. I look forward to ongoing
    Gregory> discussion about it.

    Gregory> General Comments

    GML> Sam & Dacheng, what do you want to do with this text? Do you want this to
    Gregory> go into the Design-guide document? Do you want it to stand alone as it's own
    Gregory> RFC? I was thinking that a lot of it, as currently written, feels like
    Gregory> design-guidance to the design teams. Your thoughts?

Right now, this is mostly a set of questions.
Long term, I want to see this text evolve into an O&M model for KARP.
The intended consumers would be:

* Implementors
* Operators
* management schema designers
I think that's somewhat different of an audience from the design guide.
I agree that right now, because it's stating options and describing
 questions it's sounding like it would fit great into the design guide.

    Gregory> 3. - 

> Another
> approach would be to notice that it is common to use the same
> authentication information across an area and configure the keys as a
> property of the area.  Doing so makes configuration easier in a
> common case at the expense of generality.
 
    GML> OSPF also has different security properties in that OSPF may commonly run
    Gregory> intra-domain, behind a security permiter, where the attach volume is greatly
    Gregory> reduced compared to something sitting on the Internet.

It would not surprise me if that were two.  Some of the data we saw at
the IAB workshop on unwanted traffic suggests Gthat the world on an
ISP's network or on an enterprise network Gisn't a whole lot safer than
on the open Internet.  So, I cannot personally evaluate that claim, but
it wouldn't surprise me if it were true.

> If keys are configured
    Gregory> per-area then the system may not support configuring different keys
    Gregory> for links in the same area.

    GML> Agree. Need to make sure that implementations do not prohibit per-link
    Gregory> keys vs per area keys.
OK, will add this requirement.

> Another option would be to have some
> sort of inheritance where default configurations are made per-area
> unless overridden per-interface.

    GML> that would work. This is definitely a vendor implementation option.
    Gregory> However, it's one that would assist interop greatly if we all agreed do enforce
    Gregory> the same default behavior.

Right. The reason it's here is that if we decide  to do something like
that, we can expose it in our management model.
If we don't expose this sort of thing in the management model it becomes
very messy  to implement if you want to work with whatever management we
come up with.

> An implementation could directly store the information about a given
> key in its configuration scope.  That is, if the key was configured
> on an interface, then the parameters of that key would be stored with
> the interface.
 
    Gregory> GML > This is a vendor implementation detail, about how the keys and security
    Gregory> association parameters will be stored and associated. However, one must
    Gregory> consider the use of KARP for protocols not necessarily tied to specific
    Gregory> interfaces. For example, BGP PeerA may be able to reach PeerB via multiple
    Gregory> paths, physical ports, or L3 routing interfaces (e.g. it might have 2 or 3 OSPF
    Gregory> interfaces that all can reach PeerB). I think the definition of when I want to
    Gregory> use keys has more to do with peers than with interfaces or links, specifically.

I think it depends on the protocol.
The multicast protocols really do seem to want to consider this
per-link.
However you're right that this current document neglects per-peer stuff,
which is quite important.
We were focusing on what we thought was a harder issue in an attempt to
make sure our design thoughts were in the right place.
However we need to go back and add the per-peer discussion for the next
rev.

> Alternatively, some abstract key object could be associated with multiple
> interfaces.  This approach might be more complicated but would make it easier
> to update a key if the same key were used for multiple protocols or in multiple
> configuration scopes.

    Gregory> GML > another idea is per-neighbor keys, i.e. anyone that wants to talk to me
    Gregory> uses key213, and this security association.
That works for the per-peer stuff, yes.
I don't quite see this for group keyed, am I missing something?

> 4. -
> Several methods for authentication have been proposed for KARP.  The
> simplest is preshared keys used directly as traffic keys.  In this
> mode, the traffic integrity keys are directly configured.  This is
> the mode supported by today's routing protocols.

> Preshared keys could also be used by an automated key management
> protocol.  
   
    GML> There is an in-between option, and it's the one we used in TCP-AO: a PSK
    Gregory> is used as in input on both sides to create the actual traffic keys. This is
    Gregory> helpful because then other things can be mixed in with the PSK as needed to
    Gregory> achieve additional security requirements, like connection specific information
    Gregory> for inter-connection replay protection, and direction-specific information so
    Gregory> that direction-specific traffic keys can be derived from one (confirgured) PSK.

I was aware of this but assumed that it was part of preshared keys with
a PSK.
However face-to-face discussions  with you and a couple of other people
were sufficient for me to understand why the difference is important to
expose at this level.
We'll revise appropriately.

> Certificates signed by a certification authority or some other PKI
> could be used.  The advantage of this approach is that routers may
> not need to be directly updated when peers are added or removed.  The
> disadvantage is that more complexity is required.

    Gregory> GML > I think we can say the same can be made true for the self-signed certs
    Gregory> solution.

I don't think so, but  let's explore this.

I don't think this applies to something like BGP at all.
IN BGP, you need a fair bit of per-neighbor configuration.

However, for something like RIP, you can end up talking to a new
neighbor with no configuration specific to that neighbor.

If your authorization policy is something like signed by a trusted CA
and contains the following EKU||SAN in the certificate, then you can get
the same effect: no security related configuration specific to that
neighbor.  I don't understand how to get this with self-signed
certificates since each router needs to have a set of public key hashes.
Am I missing something?

    Gregory> 4.1 -
    GML> Define "small integer" keyID? What thinking led you to qualify it that
    Gregory> way?

In a lot of our existing protocols, it is a 16 or 32-bit quantity.  It's
not an OID, HASH, URI, or the like.
That's what we mean by small integer.

> Typically key IDs
> are names valid only in the scope of one interface or peer.

    Gregory> GML > probably need to be unique per peer, that is, if we want implementers to
    Gregory> be able to use a single key table for KARP.

Ah, what I'm trying to say here is that the primary key for that table
 includes the interface identifier for group keys and the peer
 identifier for peer-based keys.  I can't think of a reason for
 requiring the key ID alone to be unique--you can make the data
 structure quite efficient either way. If you have key IDs be scoped, it
 avoids having to worry about conflicts at cross-organizational
 peerings.

> Manual preshared keys are often known by a group of peers not just
> one peer.  This is an interesting security property: it is impossible
> to identify the peer sending a message cryptographically; it is only
> possible to identify a group of peers using cryptographic means.  

    Gregory> GML > This is true if you use the PSK raw. If, otoh, you use the PSK as a key
    Gregory> derivation key for generation of a traffic key, and use peer specific
    Gregory> information, and/or connection specific information in the traffic key creation
    Gregory> operation, then one can also achieve peer ID validation, as well as replay
    Gregory> protection.

This text is mine; Dacheng pointed out a similar problem. Clearly it
needs another round of revision.
What I was trying to say is that with manually preshared keys one peer
can impersonate another.
The protocol may include a peer ID either in each packet or in
derivation of a traffic key. However this depends on the peers playing
nice.

> As
> a consequence, authorization is typically based on knowing the
> preshared key rather than on being a particular peer.  Note that once
> an authorization decision is made, the peer can assert its identity;
> this identity is trusted just as the routing information from the
> peer is trusted.  However, for the process of authorization, it would
> be more complicated to identify peers this way and would not gain a
> security benefit in most deployments.

> Care needs to be taken when symmetric keys are used for multiple
> purposes.  Consider the implications of using the same preshared key
> for two interfaces: it becomes impossible to distinguish a router on
> one interface from a router on another interface.  So, a router that
> is trusted to participate in a routing protocol on one interface
> becomes implicitly trusted for the other interfaces that share the
> key.  

    GML> same as above. This issue disappears if you use the PSK to derive a
    Gregory> traffic key. 

And you include the interface identifier.  My answer is that it sort of
disappears.  However we're giving operators advice.  Let's say that I
have two networks at different security levels.  Even if devices on the
low-security network are compromised, I don't want them to be able to
join the high-security network.  We've decided that insider attacks are
out-of-scope. However this issue strikes at the heart of determining
whether an entity is an insider or not.  Operators need to understand
that if isolation in the case of compromise is important, depending on
traffic key derivation is insufficient.  So, we'll rework the text to
actually make the intended point.  Also, we will discuss how once you
have made the base authorization decision, the type of approach you
discuss can detect misconfiguration etc.

> For many cases, such as OSPF routers in the same area, there is
> no significant advantage that an attacker could gain from this trust
> within the KARP threat model.  However, other protocols, such as RIP,
> permit routes from a particular interface to be filtered.  For these
> protocols, participation in one interface might be more advantageous
> than another.

    Gregory> GML > For RIP, it usually runs within a specific trust domain, so it may be
    Gregory> less of an issue. BGP is a great example of where your point would be very
    Gregory> applicable, as different BGP interfaces may well each be in a different trust
    Gregory> domain.

I'd hope this would not be applicable to BGP: I'd hope that a given PSK
 is known only by two organizations.

> More subtle problems with key separation can appear in protocol
> design...

    Gregory> GML > Good guidance, and nicely explained. Would the PSK as a kdf trick address
    Gregory> this paragraph too?

It can be made to. Doing so places constraints on the KDF, requires that
the PSK always and only be used with the KDF and places constraints on
the interface between the KDF and protocols.  That sounds negative; it
definitely should be done this way, but care is required.

    Gregory> As a result, we should use appropriate
    Gregory> key derivation functions so that different cryptographic keys are
    Gregory> used even when the same initial input key is used.

    GML> Ahh. There we go. Okay, so we agree that rather than specify the direct
    Gregory> use of PSK's as traffic keys themselves, we ought only specify PSK used as a
    Gregory> kdf to create traffic keys?

That would be great.
We have this huge deployed base problem though.

    Gregory> 4.2 -

    GML> after reading the section a few times, I'm wondering if what you are
    Gregory> really discussing is better labeled as asymmetric keys, rather than "public
    Gregory> keys"?

Yes.
Thanks.

    Gregory> The Session
> Description Protocol provides a standardized mechanism for naming
> keys (in that case certificates) based on hashes.

    GML> [nit] reader would be served by an inline ref
It shall be so.
> KARP SHOULD adopt
> this approach or another approach already standardized within the
> IETF rather than inventing a new mechanism for naming public keys.

    Gregory> GML > Agreed 100%. 

> A public key is typically expected to belong to one peer.  As a peer
> generates new keys and retires old keys, its public key may change.
> For this reason, from a management standpoint, peers should be
> thought of as associated with multiple public keys rather than as
> containing a single public key hash as an attribute of the peer
    Gregory> object.

    GML> Good point. Agreed.

> However management interfaces need to
> be carefully designed to avoid making this extra level of indirection
> complicated for operators.

    Gregory> GML > Agreed. Probably helps to add an example or be more specific by providing
    Gregory> some design tips

    Gregory> 4.3 - 
> An advantage of this is that it may
> be possible to add a new router with no authentication related
> configuration of the peers of that router.

    GML> do you have a specific example in mind? I'd like to hear more about how
    Gregory> you think this could be accomplished.

For any routing protocol, I say that a peer with a particular trust anchor and otherName form of the SAN is permitted to be my peer.
I haven't saved on router-protocol configuration.
For BGP, it's unclear this is interesting.
For RIP, I probably need no configuration at all to add a new peer, although I bet the overlap between people who use RIP and who deploy PKI is minimal.

An interesting case here is how much this helps us with RSVP-TE.

> Assuming that potentially self-signed certificates are used by
> routers that wish to use public keys but that do not need a PKI, then
> PKI and the infrastructureless mode of public-key operation described
> in the previous section can work well together.  One router could
> identify its peers based on names and use certificate validation.
> Another router could use hashes of certificates.  This could be very
> useful for border routers between two organizations.  Smaller
> organizations could use public keys and larger organizations could
> use PKI.
 
    Gregory> GML > Our thinking is aligned exactly here. Based on all my years of IPsec
    Gregory> implementation experience with organizations, I'd say we are likely to get a
    Gregory> LOT more deployment from the self-signed certs and the infrastructureless mode
    Gregory> of public-key operation than we are from genuine PKI. The later will be used,
    Gregory> by by a niche of the market, whereas the former could be deployed easily, with
    Gregory> little infrastructure or config, and therefore has a far greater chance of
    Gregory> broad deployment of KARP.

Agreed!

    Gregory> 4.4 -
    Gregory> GML > I think we will see the design and use of central servers before this is
    Gregory> all over in KARP. I continue to feel, as you penned, that we'll need them for
    Gregory> mcast'ing protos. I suggest we focus on the simpler mechanisms for leveraging
    Gregory> asymmetric keys, i.e. self-signed certs plus flat-file whitelists so that we
    Gregory> have some basic tools for implementation and further testing/experimentation.

    Gregory> 7.0 -
    Gregory> GML > when you say "phased upgrade from manual keying to automated key
    Gregory> management" what would those phases look like? Do you mean a network goes from
    Gregory> manual to PSK as kdf, then from PSK-in-kdf to self-signed certs + flat-file
    Gregory> whitelist. Then from there to full PKI? Or are you actually saying that when
    Gregory> moving from one of these to another it must be able to occur without a halt in
    Gregory> adjacency?

This is something that Dacheng brought up as a vendor. Ffrom an
    operational standpoint we need to be able to tell an organization
    how to move from what we have today to what we want them to have.
    It's OK to reboot each router at some point in the process: you
    need to install new software for example. So, the adjacencies will
    bounce.

However consider what happens when you upgrade a multicast link.  You
go through a phase where you get new software onto all the routers.
Now, all the routers can support the software.  You want to move the
link from say manual PSKs for traffic keys to something else.  It
might be OK to break the adjacencies one-by-one (although I doubt
that's necessary).  It is probably not OK to break all adjacencies on
the link.  So, I'm guessing that if we have something like Russ's
manual key tables, you'll want to have a couple of rows populated by
the old manual traffic keys and a couple of rows populated by the new
keys.

For peer-to-peer protocols it may be less of an issue.