Subject: [karp] Negotiation

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Jan 2011 11:03:11 -0500

At the last meeting, Yinxing Wei asked about our strategy for
negotiation of cryptographic parameters.

I think this is an important discussion to have.  It's another area
where I think we may find the security area's default assumptions differ
from the routing area.

I don't have strong opinions on what the answer is, so perhaps I can try
and outline both sides as I understand them.  Perhaps this will help get
things started.

Routing protocols have a fair bit of configuration. For BGP, you need to
configure peers, AS information and a heck of a lot of policy. Even for
something like OSPF and IS-IS that try to have a fair bit of automated
discovery, you need to indicate what area an interface is in. This
configuration needs to be consistent and synchronized. As a result,
anyone who has more than a couple of routers has mechanisms for managing
and updating configuration. Updating what cryptographic algorithms to
use in a configuration is not that difficult.

One highly undesirable thing in an operational network is when some
change has unexpected consequences. Here are a couple of situations that
might help understand why an operator is nervous about negotiation. Two
peers (A and B) negotiate cryptographic authentication. Before an
upgrade, everything is working. B supports SHA-1 and SHA-256, but A only
supports SHA-1. A is upgraded and now supports SHA-256. Unfortunately,
B's implementation of the routing authentication using SHA-256 is
buggy. The upgrade causes things to break.  Perhaps you'll argue that's
not really an unintended consequence: upgrades sometimes expose bugs in
the systems involved in the upgrade.

However, negotiation can make problems far more hidden. Consider a
network with routers A, B and C. B and C support SHA-256 and SHA-1, but
A currently only supports SHA-1. Some protocol with a group key is
in-use. A is upgraded; as a result the communication between B and C
happens. This can be the case if C's implementation of SHA-256 does not
work with B. So, even though neither of the parties directly involved in
the communication changed software or configuration, the set of
capabilities on the network changed, which changes what is used.

On the other hand, negotiation in security protocols is useful. Users
don't tend to update configurations. Also, the more you have to
configure, the harder it is to get security working. If security
parameters can be determined automatically without compromising
security, usability is increased. Negotiation will lead to the gradual
deployment of better protocols as software is updated. So, negotiation
is desirable.

Our job is to balance these tradeoffs.

---

From: [email-masked]
Date: Wed, 19 Jan 2011 16:22:31 +0800

Hi Sam,

Welcome the discussion on negotiation! Very appreciated ^_^

It is me that did the presentation on site and asked for negotiation due 
to the requirement for algorithm agility. My name is Xiaoping Liang, may 
be a bit complex to you, and you may call me Ellen ^_^

What you pointed out in the email is very importment, and negotiation 
directly for routers in current use without more work will DO introduce 
risks, and even bring out severe consequences. But without negotiation, it 
is very difficule to achieve better security and better 
interoperation/interconnection. Yes, I do agree, as engineer, our job is 
to balance these tradeoffs. And we need to do MORE work to make 
negotiation less risky besides configuration. 

The unwanted consequences you pointed out when using negotiation come from 
implementation and deployments of cryptographic algorithms or security 
mechanisms in the routers. I think the problem will be solved finally.

Cheers,
Ellen (Xiaoping Liang)

Sam Hartman <[email-masked]> 
发件人:  [email-masked]
2011-01-14 00:03

收件人
[email-masked]
抄送

主题
[karp] Negotiation

Our job is to balance these tradeoffs.
_______________________________________________
karp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/karp

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Jan 2011 09:05:23 -0500

>>>>> "liang" == liang xiaoping <[email-masked]> writes:

    liang> What you pointed out in the email is very importment, and
    liang> negotiation directly for routers in current use without more
    liang> work will DO introduce risks, and even bring out severe
    liang> consequences. But without negotiation, it is very difficule
    liang> to achieve better security and better
    liang> interoperation/interconnection. 

One thing we should do is write up the clear advantages of negotiation.

I think the main advantage is that it permits deployment of new
cryptographic algorithms via the gradual process of upgrading software
and equipment without the explicit action of operators to do so.
Are there other significant advantages in the KARP context?

---

From: [email-masked]
Date: Fri, 21 Jan 2011 15:45:41 +0800

Hi Sam,

Yes, I do agree. First, we could figure out why we need or don't need 
negotiation. If the answer is yes, then we could figure out what to 
negotiate, and how to negotiate. 

> and equipment without the explicit action of operators to do so.
Yes, that's one strong advantage that supports negotiation. 

> Are there other significant advantages in the KARP context?
Yes. In section 1.1 of the document threats-reqs-01, it says that
 "A KMP is helpful because it negotiates unique, pair wise, random keys 
without administrator involvement.  It also negotiates as mentioned 
earlier several of the SA parameters required for the secure connection, 
including key life times.  It keeps track of those lifetimes using 
counters, and negotiates new keys and parameters before they expire, 
again, without administrator interaction.  Additionally, in the event of a 
breach, changing the KMP key will immediately cause a rekey to occur for 
the Traffic Key, and those new Traffic Keys will be installed and used in 
the current connection."

And I can see from the above paragraph that the advantages of negotiation 
include:
1. It makes KMP provide unique session keys for routing protocols without 
administrator involvement. Session key is called traffic key in the 
document threats-reqs-01. 
2. It makes KMP have flexibility to manage SA, including key lifetime and 
other parameters of SA. 
3. It makes KMP have the ability to recover routing systems immediately in 
the case of security breach, and that seems very good.

Other findings or opinions about the advantages of negotiation in KMP from 
other people? 

Cheers,
Ellen (Xiaoping Liang)

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 Jan 2011 07:39:32 -0500

>> Are there other significant advantages in the KARP context?
    liang> Yes. In section 1.1 of the document threats-reqs-01, it says
    liang> that "A KMP is helpful because it negotiates unique, pair
    liang> wise, random keys without administrator involvement.  It also
    liang> negotiates as mentioned earlier several of the SA parameters
    liang> required for the secure connection, including key life times.
    liang> It keeps track of those lifetimes using counters, and
    liang> negotiates new keys and parameters before they expire, again,
    liang> without administrator interaction.  Additionally, in the
    liang> event of a breach, changing the KMP key will immediately
    liang> cause a rekey to occur for the Traffic Key, and those new
    liang> Traffic Keys will be installed and used in the current
    liang> connection."

I find that paragraph kind of muddled because it combines the advantages
of negotiation with the advantages of the KMP.  I think we're at least
chartered to believe that having a KMP is good. I understand there are
participants who disagree with that, but I think we're beyond that
argument.

So, I think fresh traffic keys, managing SA lifetimes and easier
rekeying are inherent properties of a KMP and are not effects of
negotiation.

>From the above I do see one advantage specific to negotiation: dealing
with overlapping parameters that are not identical. That is, if one side
permits algorithm A and B, but the other side permis B and C, then the
connection can take place with B.
Without negotiation, the configuration will need to be exactly in sync.

I would love to hear from operators to what extent this is actually an
advantage.

---

From: [email-masked]
Date: Fri, 21 Jan 2011 21:20:48 +0800

Sam> I find that paragraph kind of muddled because it combines the 
advantages
Sam> of negotiation with the advantages of the KMP.  I think we're at 
least
Sam> chartered to believe that having a KMP is good. I understand there 
are
Sam> participants who disagree with that, but I think we're beyond that
Sam> argument.

I agree that having a KMP is good, since there is a market demand, and KMP 
is more advantageous than manual keying, and can remove some problems 
occurred in manual keying. 

In my personal opinion, negotiation is one function or ability/capability 
of KMP, and is very important to automated KMP, especially in secure 
channel establishment. 

Sam> So, I think fresh traffic keys, managing SA lifetimes and easier
Sam> rekeying are inherent properties of a KMP and are not effects of
Sam> negotiation.

In essence, yes. Could KMP make these properties reality without 
negotiation? Negotiation makes KMP more powerful and realize those 
properties at least. 

Sam> From the above I do see one advantage specific to negotiation: 
dealing
Sam> with overlapping parameters that are not identical. That is, if one 
side
Sam> permits algorithm A and B, but the other side permis B and C, then 
the
Sam> connection can take place with B.
Sam> Without negotiation, the configuration will need to be exactly in 
sync.

Yes, that is one aspect of algorithms agility, and negotiation makes 
configuration more easy and flexible. 

Sam> I would love to hear from operators to what extent this is actually 
an
Sam> advantage.

Me, too ^_^
Cheers,
Ellen (Xiaoping Liang)
--=_