Subject: [karp] I-D ACTION:draft-ietf-karp-design-guide-01.txt

From: [email-masked]
Date: Thu, 9 Sep 2010 21:30:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Keying and Authentication for Routing Protocols Working Group of the IETF.

	Title		: Keying and Authentication for Routing Protocols (KARP) 
Design Guidelines
	Author(s)	: G. Lebovitz, M. Bhatia
	Filename	: draft-ietf-karp-design-guide-01.txt
	Pages		: 28
	Date		: 2010-9-8
	
In the March of 2006 the IAB held a workshop on the topic of 
      "Unwanted Internet Traffic".  The report from that workshop is 
      documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls 
      for [t]ightening the security of the core routing 
      infrastructure."  Four main steps were identified for improving 
      the security of the routing infrastructure.  One of those steps 
      was "securing the routing protocols' packets on the wire."  One 
      mechanism for securing routing protocol packets on the wire is 
      the use of per-packet cryptographic message authentication, 
      providing both peer authentication and message integrity.  Many 
      different routing protocols exist and they employ a range of 
      different transport subsystems.  Therefore there must 
      necessarily be various methods defined for applying 
      cryptographic authentication to these varying protocols.  Many 
      routing protocols already have some method for accomplishing 
      cryptographic message authentication.  However, in many cases 
      the existing methods are dated, vulnerable to attack, and/or 
      employ cryptographic algorithms that have been deprecated.  
      This document is one of a series concerned with defining a 
      roadmap of protocol specification work for the use of modern 
      cryptographic mechanisms and algorithms for message 
      authentication in routing protocols.  In particular, it defines 
      the framework for a key management protocol that may be used to 
      create and manage session keys for message authentication and 
      integrity.  The overall roadmap reflects the input of both the 
      security area and routing area in order to form a jointly 
      agreed upon and prioritized work list for the effort.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-karp-design-guide-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: mark Brown <[email-masked]>
Date: Tue, 14 Sep 2010 01:18:24 +0530

Hi Gregory and Manav,

First of all, thanks for the update - am glad that most of the
comments have been incorporated.

Having read the document I think i am a little unsure of what the
final deal is with the key chains - Do we recommend using them or do
we dont?

Mark

On Fri, Sep 10, 2010 at 10:00 AM,  <[email-masked]> wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 14 Sep 2010 06:29:55 +0530

Hi Mark,
 
> comments have been incorporated.

Thanks!

> final deal is with the key chains - Do we recommend using them or do

Depends on why you're using them. 

Lets be clear on one thing - Key chains don't help you security-wise, i.e., if an operator leaves the company one still has to change *all* the keys; doesn't really matter if you have one or "n" keys in your key-chain, as the operator had access to them all. So key-chains don't help you here.

IMO, we could have an incremental approach where we have keys in the key-chain which are used as master keys from which we derive the traffic keys. We could additionally associate a receive and a send life time with each key. This could be done till the key-store becomes ubiquitous.

If we want to be able to move from the ability in a routing protocol that cannot roll over keys, even from a key-chain of keys today, to a protocol that can do this without yet having a fully automated in-band key management system available, then we have to decouple the two things. This would be the step 1.

Note that key chains will NOT help you if your routing protocol transport subsystem does not support gracefully rolling over to the new keys without bouncing/breaking the adjacencies. So, the step 1 is to fix all routing protocols so that they can change keys (key agility) without breaking/bouncing adjacencies.

Cheers, Manav

> > This draft is a work item of the Keying and Authentication 
> for Routing Protocols Working Group of the IETF.
> >

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 15 Sep 2010 21:30:11 -0700

I am having a couple of problems with section 2.2

1.  It is not clear to me that the correct description in the introduction
is that of distributing session keys.  I think that one of the things we
really want to look at is the removal of session key distribution and deal
with distribution of master keys instead.  However, it is not clear that the
methods of distributing the master or session keys has anything to do with
the topology of the routing protocol.   Suggested text:

The second axis of categorization groups protocols by the keying
associations for the Routing Protocol Transports.  The question at hand is
what keying material is shared between the peers.

2.  It is not clear to me that there is not the possibility of a one-to-many
keying method.  It may be that we have eliminated the ability to use
asymmetric keys (targeting an ECDSA signature) but I do not remember this as
being an absolute.  I don't believe we have ever stated that anything other
than authentication of source material is a requirement.  If we allowed for
this then it would be possible to have a one-to-many keying association.  I
think that it is possible that some one-to-many routing protocols may be
willing to pay the price of a slightly bigger authentication token in order
to keep the semantics of the one-to-many rather than go to a many-to-many or
one-to-one security model.  Even if we have decided that we will only be
using MACs for the purpose of authentication, it might be worthwhile briefly
discussing the option.

In section three I wonder about the following:

1.  Does the second paragraph mean that RFC 4107 SHOULD NOT be considered?
This is how I read the However at the front of the sentence.  The word
However can probably just be deleted.

2.  For the word Consider in paragraph 3 -- I assume that what you mean by
this is "Examples of parameter that might need to be considered are:"

3. I believe that adding a brief description of the KMP protocol in this
section would be a good addition.  It does not need to be a full
description, copying the definition from the framework document would be
sufficient.

4.  Personal Opinion: I would currently rather use TKNP (Transport Key
Negotiation Protocol).  This is really a chance for you to enlighten me if
this protocol is supposed to do anything more than negotiate the set of
parameters needed to derive the transport key as well as use it.  (I suppose
if both entities had RSA public/private keys they would need to transport a
master key rather than have it implied either from key agreement keys or
configured shared secrets.) 

5.  The text in section 2 says  "KMPs replace the need for humans, or OSS
routines,  to periodically replace keys on running systems."  I have my
doubts about this.  I think that OSS routines for doing the configuration
and propagation of secrets may still be required (if for example the KMP
uses a set of shared secrets between two routers).  However this text got me
messed up for a while on what the KMP protocol was supposed to be doing.
Specifically from this point of view I would think that it might do some of
the provisioning of routers.

6.  In section 3.2 I think it would be useful to have a somewhat expanded
discussion of bouncing of adjacencies.  The elements that I would like to
see covered would be:  a) why would an existing protocol do the bouncing, b)
under what circumstances would it be reasonable to permit bouncing in the
future.  An example of a case where I think it might not be a bad idea would
be if a browser is re-provisioned with a new secret for an adjacency.   It
may be that I am completely out to lunch here, and I don't know if this
situation would bounce all adjacencies or just the ones with new secrets.

7.  In section 3.2 the second paragraph talks about key lifetimes.  However
it is not clear what one is looking at and how one would measure a lifetime
of a key.  Examples of what I am talking about.  If one derives a transport
key from a master secret, this can be rolled over frequently without any
problems and deal with somebody discovering the transport key.  However
there is a different level of problem if the attacker can discover the
master secret or shared secret.  Are we saying that these need to be rolled
over "frequently" or not?  One can say that the amount of times that a key
is used is one measure of how frequently the key needs to be changed.
However one cannot use the KMP to do the key roll over of the master secret.
If the attacker has discovered the master secret then using it to send the
new master secret would leak the new master secret to the attacker and thus
not lead to any more security.  This would be a distinction between the KMP
being an inter-router protocol and the KMP being a router provisioning
protocol.

Putting the distinction between the differences followed by the
justification might be a more logical progression.  (I.e. this is what we
should look at and this is why it should be looked at.)  Thus the 4th
paragraph in some respects follows from the 2nd paragraph.  But does not
appear to address the 3rd paragraph.  I.e. if the router is subverted, then
one should still do frequent key roll overs rather than infrequent manual
ones.

8.  I would like a definition of what you mean by a key chain.  Do you
consider a sequence of transport keys derived from a single master secret
being a key chain or is this only a concept of a series of keys that are
changed based on some well-defined event.

Do I have any reason to believe that all of the current router protocols
currently support whatever you mean by a keychain?  (Minor point-- is it
keychain or key chain.)

Section 4 comments questions and issues:

1.  Because I have not clear understanding of what the KMP protocol is
actually supposed to be doing, I find that the breakdown of the work and
what the differences between the different phases are.

a)  Post Phase one -- A the present point I believe that the changes are
going to be:
1) All messages will be authenticated
2) All messages will carry the information needed to identify a key to be
used
3) All authentication will be done using "modern" algorithms
4) Given that no KMP exists, the transport key will be a shared secret and
not change based on any criteria.
5) A RECOMMENDATION would be that the implementers separate the key code
from the transport code.  But there is no actual way to either test this or
the fact that changing keys would not cause bouncing of adjacent nodes.

b) Post Phase two - the KMP would exist and allow for adjacent routers to do
negotiation of master secrets (if public/private keys are used) and key roll
over based on messages exchanged.  (i.e. I am about to roll over the key and
this is the new ID - ok?)

>From this I think that one can draw the conclusion that I find the entire
section to be confusing as to what the actual goals are and when they are to
be obtained.  

2.  In section 4.2 - Define Optimal State - When you say manual keys - are
you implying that these are single long term manual keys that have no KDF
included?  Do you believe that it is allowed for a single mater key to be
used, or does it need to be specified in such a way that each key (as
characterized in section 2) is different and is possibly different in each
direction? (And yes this does allow for an operator to use a single secret
in all cases.)

3.  Transition Considerations -- If looking at the requirement to bounce
adjacencies, it is possible to describe different situations where the
adjacent routers are configured at close to the same time and at a times
which are not close?  I.e. there may be different considerations where one
is doing inter vs. intra domain transitions.  There may be differences in
cases where a good OSS exists as oppose to an operator using a web browser
on each router (and thus potentially typing things incorrectly.

4.  Should there be a "And possibly repeat - on the process as feedback is
returned from actual implementations and rollouts?"

5.  KMP analysis.   "decoupled with  the KMP"  I don't understand this
phrase.  Are you decoupling from a specific KMP and into a general KMP?  Are
you decoupling from the KMP and putting into the routing protocol?  Do you
really mean to say decoupled from the routing protocol?

6.  Phase 2 Gap Analysis - would this not be the KMP analysis.  I would
assume that none of this would exist unless it was pushed back into phase 1
for some reason.

7.  Phase 2 should have a Transition and Deployment Considerations analysis
done.

I need to get some other work done, but want to get this in.  So I will look
at the rest of the document at a later time.

Jim

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 22 Sep 2010 17:26:52 +0530

Hi Jim,

Thanks for the review!

I'll reply to your original mail in parts so that its easier to track the issues that you have raised.

> However can probably just be deleted.

Yup, that's correct. Will do that.

> this is "Examples of parameter that might need to be considered are:"

Yes, that's precisely what I had meant. Will update this.

> description, copying the definition from the framework 

I am trying to understand your point - Are you suggesting that we add some text in this section that explains what a key management protocol is and does? Wouldn't this be obvious to someone who is reading a design guide document? If folks think that this may not be the case, then sure I can add some text that explains what a key management protocol is in the next revision. 

> see covered would be:  a) why would an existing protocol do 

You could not, pre RFC 5310 change keys in IS-IS without bouncing sessions since there was no concept of Key ID back then.

> future.  

I cant imagine any scenario under which it would be acceptable for a routing or a signaling protocol to ever bounce the adjacencies/sessions.

> one should still do frequent key roll overs rather than 

I agree that there is a huge scope of improvement in Section 3.2. I wanted to capture the two opposing sentiments - one which says that keys should be frequently rolled over lest they get discovered and security of a system gets compromised. There is also a small bunch that feels that keys should be rolled over as they can be cryptographically broken - I disagree with them. There is another strong opposing sentiment that says that we shouldn't frequently change the keys as its when one is changing the key that there is a maximum probability of it being leaked/disclosed.

I also say the following in this section:

In general, where strong cryptography is employed, physical, procedural, and logical access protection considerations often have more impact on the key life than do algorithm and key size factors.

> changed based on some well-defined event.

The latter.

> currently support whatever you mean by a keychain?  (Minor 

This is an implementation specific issue and most vendors imo are already supporting this.

> point-- is it

Key Chain.

Cheers, Manav

---

From: Sam Hartman <[email-masked]>
Date: Tue, 28 Sep 2010 10:24:29 -0400

Jim, I generally agree with the review comments you made.

I think a lot of confusion is coming down to one of Eric's many issues:
can we actually get to a point where we're deriving transport keys from
master secrets. I also think there is a related issue surrounding the
boundary of the KMP .  I think that these sorts of issues are behind a
lot of my confusion with parts of the design guide and with Russ and
tim's drafts.

A group of us got together after the session to discuss how this
interacts with multicast routing protocols. I think we'll have some
results to share by the 00 cutoff.  I suggest that we may want to use a
significant chunk of our meeting time in China to actually work through
how key derivation will be and where the boundaries between various
types of keys will be.  Until we do that I think different people will
read the design guide to say entirely different things.  I know I at
least read different sections of the design guide differently.

I also think that we should address your question about asymmetric
signatures quickly. If we're willing to approach that, it opens some new
options but also complicates the architecture. However if we're not
going to use asymmetric signatures, we can make significant simplifying
assumptions. The sooner we can resolve that issue, the better.

--Sam

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 29 Sep 2010 13:11:11 -0700

I look forward to seeing what you have in the new draft.

I think that we really need to determine what security requirements we have
on some of the protocols before we can rule in or out asymmetric signatures.

Jim

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Tuesday, September 28, 2010 7:24 AM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [karp] I-D ACTION:draft-ietf-karp-design-guide-01.txt
> 
master
> secrets. I also think there is a related issue surrounding the boundary of
the
> KMP .  I think that these sorts of issues are behind a lot of my confusion
with
> parts of the design guide and with Russ and tim's drafts.
> 
> A group of us got together after the session to discuss how this interacts
with
> multicast routing protocols. I think we'll have some results to share by
the 00
> cutoff.  I suggest that we may want to use a significant chunk of our
meeting
> time in China to actually work through how key derivation will be and
where
> the boundaries between various types of keys will be.  Until we do that I
think
> different people will read the design guide to say entirely different
things.  I
> know I at least read different sections of the design guide differently.
> 
signatures
> quickly. If we're willing to approach that, it opens some new options but
also
> complicates the architecture. However if we're not going to use asymmetric
> signatures, we can make significant simplifying assumptions. The sooner we
> can resolve that issue, the better.
> 
> --Sam