Subject: [karp] just use IKE(v2)

From: "Dan Harkins" <[email-masked]>
Date: Sun, 3 Apr 2011 15:22:24 -0700 (PDT)

Hello,

  During the karp meeting on Friday I brought up the issue of using
IKE(v2) as a key management protocol for karp or rolling-our-own.
Based on comments I received after the meeting it is apparent I
explained myself poorly. Let me try again.

  I think it is important to explore rolling-our-own key management
protocol that is customized to the task at hand. The WG may eventually
decide not to go that route, and to just use IKE(v2), but I think we
should weigh the pluses and minuses of both before we start saying
things like, "oh well we're just gonna use IKE(v2)" (and a thousand
pardons up front if I'm mischaracterizing anyone with that statement).

  The way I see it is, we could use IKEv1 and define another DOI, or we
could graft on a DOI concept on to IKEv2 and use that. The former seems
correct since that's what the DOI was for, but people want to discourage
the proliferation of IKEv1. The latter uses IKEv2 (which pleases the
people discouraged by the proliferation of IKEv1) but adds on a
complication that was intentionally left off the rev of IKE. And
both of those have a security issue that would be exploited by their
expected use.

  Today operators configure a shared key on their routers to use for
securing BGP traffic. They are comfortable with that UI and would
probably resist complications in their lives. So it would make sense to
use a key management solution in karp that didn't have a security
problem when used with a pre-shared key. Neither IKEv1 nor IKEv2 qualify
in that regard, they are both susceptible to dictionary attack.

  IPsecme tried to come up with a single standardized solution to that
problem but the result is 3 competing ones. Even picking one of those
means that the IKEv2 exchange has grown from 4 messages to 6. And it,
effectively, doubles the public key crypto operations. That's might be
a price the WG is willing to pay. The WG might even decide that the
security issue with pre-shared keys in IKE(v2) isn't worth addressing.
But here's another possibility.

  It's possible to implement a protocol that accomplishes authentication,
key agreement, and key confirmation (important characteristics of any
key management protocol), using only a pre-shared key, and to do it in
just 3 messages, with less crypto operations than is done in IKE today.
What's more, this protocol would be resistant to dictionary attack.

  The EKE patent expires in a few months so it's possible to have a
solution free of IPR worries, with some finessing of the Diffie-Hellman
groups. It's also possible to use an unpatented protocol whose IPR
situation is a little more questionable (it's what Donald Rumsfeld
referred to as "the known unknowns and the unknown unknowns"), that
could use any of the Diffie-Hellman groups defined in IKE today (both
EC and MODP).

  That seems compelling to me. We give the operators the same
comfortable UI they've come to expect but insert robust, misuse
resistant, and provably secure cryptography underneath.

  Or we can just use IKE(v2).

  But it would be nice to discuss the possibilities before we get too
far down one path (which it seemed like we were doing last Friday).

  regards,

  Dan.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Apr 2011 15:18:21 -0400

Dan brings up an interesting question.

>From an operational standpoint is it acceptable for us to use assume
that the preshared keys we have are reasonably strong?

I hope the answer is that we can assume they are sufficiently
strong. Doing so has significant simplicity assumptions. IN particular,
we avoid having to deal with the password authenticated key exchange
problem, which has crippled multiple working groups ability to make
forward progress on an issue. Examples include SACRED, IPSECME, and I
believe others.

I think that the levels of security provided by SCRAM, Kerberos, and
other mechanisms that have not encountered significant process problems
will be adequate, particularly protected by a DH exchange.

What this means is that an active attacker can potentially mount a
dictionary attack.
There are a *lot* of real world systems that have made the security
decision that risk is acceptable.
I think we should join the crowd.

If a PAKE solution should suddenly appear that has broad support in the
IETF, we can pick it up.
I do not think we need to bite off unnecessary tasks that multiple WGs
have failed at: we have enough of a challenge already.

I consider PAKE a really nice to have, not a necessary requirement.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Apr 2011 15:23:39 -0400

Dan, I think I correctly understood what you were proposing.

I'm not sure I'm proposing the same thing or not.

I think we should start from IKEv2.
I do not believe that we should formally build in a DOI concept into
IKEv2.
Instead, I think we should take IKEv2, copy it and evolve
semi-independently to form a KMP that meets our needs.
So, I'm proposing rolling our on, but I'm proposing that we not start
completely from scratch.

My suspicion is that we will have a relatively small number of
differences between our protocol and IKEv2, similar in quantity and
complexity to the small number of differences between TLS and DTLS. The
source of these differences will be different: rather than differences
between UDP and TCP it will be differences caused by domain.  so, I
suspect it will be possible that we can allow future extensions to IKEv2
to equally apply to our protocol.  For example, we can allow PAKE
messages for IKEv2 to be used if we should choose.

However, I do not propose to introduce the DOI concept into IKEv2.

I do not support using IKEv1 at all.  IKEv2 seems like a much cleaner
protocol.  I'd much rather be working on it than IKEv2. I find reasoning
about IKEv1 more challenging, even though in some sense it has more
abstractions.

These are my thoughts.
I will be very interested to hear from others.

---

From: Sean Turner <[email-masked]>
Date: Wed, 06 Apr 2011 15:31:35 -0400

On 4/6/11 3:23 PM, Sam Hartman wrote:

snip..

> However, I do not propose to introduce the DOI concept into IKEv2.

Somebody has introduced the concept of GDOI into IKEv2:

https://datatracker.ietf.org/doc/draft-yeung-g-ikev2/

> about IKEv1 more challenging, even though in some sense it has more

IKEv1 is obsolete and any references to it will cause all kinds of 
procedural problems.

> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Apr 2011 15:51:12 -0400

>>>>> "Sean" == Sean Turner <[email-masked]> writes:

    Sean> On 4/6/11 3:23 PM, Sam Hartman wrote:
    Sean> snip..

    >> However, I do not propose to introduce the DOI concept into

    Sean> Somebody has introduced the concept of GDOI into IKEv2:

    Sean> https://datatracker.ietf.org/doc/draft-yeung-g-ikev2/

That draft seems to accomplish adding multicast IPsec to IKEv2.  That to
me doesn't sound like a new DOI or a DOI concept.  (The fact that the
protocol has DOI in its name not withstanding.)

The authors may have intended--I can't really tell--to do something that
could key groups that were not IPsec groups.
I don't have confidence they succeeded: there seem to be a lot of
IPsec-specific assumptions scattered throughout the draft.

This is definitely an interesting draft to track, especially for those
of us working on multicast keying for KARP.
It doesn't seem though that it really adds the DOI concept from IKEv1 in
all its formality to IKEv2.

---

From: Russ Housley <[email-masked]>
Date: Wed, 6 Apr 2011 16:42:37 -0400

I think we need to focus on incremental improvement.  Today, there is essentially no way to roll from one key to the next.  If we can provide this capability, then there will be an incentive to use strong keys.  Today, there is no such incentive.  So, let's assume that strong keys will be used once a simple roll-over capability is available.

Russ

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 6 Apr 2011 14:41:58 -0700 (PDT)

Hi Russ,

On Wed, April 6, 2011 1:42 pm, Russ Housley wrote:
> I think we need to focus on incremental improvement.  Today, there is
> essentially no way to roll from one key to the next.  If we can provide
> this capability, then there will be an incentive to use strong keys.
> Today, there is no such incentive.  So, let's assume that strong keys will
> be used once a simple roll-over capability is available.

  I'm not following this at all. One would think that if there was a
way to seemlessly roll from one key to the next that a given key would
be less "strong", since it's not gonna last very long and will soon be
rolled out in exchange for the next.

  I think the only way we can reasonably answer that question is to look
into how the first key is provisioned. If it's Joe from ISP A calling
Fred from ISP B on the phone and saying, "enter w-3-8-g-capital-P-x-..."
then I think the answer is "probably not." Such a technique is error
prone if the pre-shared key is too "strong".

  Hi Sam,

>> forward progress on an issue. Examples include SACRED, IPSECME, and I

  The EKE patent is expiring in a couple of months so the reasons for
the failure of SACRED should not apply. The failure of PAKE in IPsecme
was due to the WG leadership and I don't believe we'll have any of those
problems here.

>> I think we should join the crowd.

  Following the crowd is a horrible reason to do anything.

>> I consider PAKE a really nice to have, not a necessary requirement.

  Like I said, the EKE patent is expiring in a couple of months. The
broad support that's needed is here in KARP.

  regards,

  Dan.

---

From: Brian Weis <[email-masked]>
Date: Wed, 6 Apr 2011 17:29:00 -0700

> protocol has DOI in its name not withstanding.)

Actually, the G-IKEv2 protocol noted above doesn't have DOI in it's name ... it's titled "Group Key Management using IKEv2". 

> IPsec-specific assumptions scattered throughout the draft.

It is not intended to be IPsec-specific, although currently only supports IPsec. Without a careful read the fact that there is ample namespace available for passing non-IPsec policy probably isn't obvious. And the mechanism for passing keying material is entirely unrelated to IPsec. G-IKEv2 would simply need to define a new GSA TEK Payload type for OSPF, IS-IS, PIM, etc. An example of what the GSA TEK payload would like can be found in <http://tools.ietf.org/html/draft-weis-gdoi-mac-tek-02>, although this I-D is meant for GDOI not G-IKEv2 so it's just an example.

> all its formality to IKEv2.

Correct, it does not.

Brian

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Thu, 07 Apr 2011 02:34:46 +0000

>> prone if the pre-shared key is too "strong".

I think Russ indicated that if there is an automatic key management system we can quickly revoke the first key with the stronger one in case the first key is weak. In the extreme condition, we can start a key revocation process at the very beginning of the execution of the whole system. For example, we use the "weak" key (e.g., exchanged through a phone call ) to generate a new stronger key (e.g., use the weak key to secure an authenticated DH exchange), and then use the newly generated stronger keys in the subsequent communication. Of course, he does not answer whether we can assume the first key distributed through a "out of band" way is strong enough or not.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 6 Apr 2011 22:51:31 -0400

> I think we need to focus on incremental improvement.  Today, there is essentially no way to roll from one key to the next.  If we can provide this capability, then there will be an incentive to use…

yes, this 1000 times... I missed, due to 'unfortunate scheduling' of
grow over karp (what the F!?!?!), karp where I was hoping to have this
very discussion.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 6 Apr 2011 22:58:08 -0400

> that the preshared keys we have are reasonably strong?

why are you injecting your ideas of password strength into the
standard? does it matter if I have 1 char for a passwd or 15 non-alpha
mixedup jumbles? (aside from 1 char is dumb because it's ... 1char)

Perhaps put another way: "What is a 'strong' preshared key?"

> strong. Doing so has significant simplicity assumptions. IN particular,

some folks use 'strong' passwords, some folks use 'cisco' (or other
similar dictionary-esque words). I don't think that matters as much as
the fact that once set ... they are unchangeable (essentially at
least).

> What this means is that an active attacker can potentially mount a

keep in mind that long before most dictionary attacks are successful
... the router will have rebooted several thousand times. Keep in mind
that your cell phone (anything of the modern 'smart phone' set) has
more CPU power than almost every router in the field today.

> I consider PAKE a really nice to have, not a necessary requirement.

seriously, the most critical problem today is that once set, a
passwd/key on a bgp or ospf/isis session is essentially never going to
change, since the mechanisms to enable that change simply don't exist.

(I note that some folks have implemented ospf key management/change
procedures, and ibgp changes were done at one very large network, but
the inter-dependencies and failure scenarios are ... horrific beyond a
few routers. The end effect is that these keys never change. If you
could simply configure a second/third/fourth key and reliably roll
those ... lots more goodness would be possible.)

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 6 Apr 2011 23:02:24 -0400

> rolled out in exchange for the next.

the problem today is you probably have to type it in, you probably
have to remember what it is (or be able to tell simply by looking at
it: "g-o-o-g-l-e .. yes, that's right!" If you could change keys
easily it may make more sense for you to just implement some system to
shovel new key material out to devices 'weekly' and then just make
that key 'dd if=/dev/urandom bs=512 count=1 | md5sum' (or some
similarly not-human-genrated-manner).

> Fred from ISP B on the phone and saying, "enter w-3-8-g-capital-P-x-..."

that's about it, or it's emailed in plain text ... :) w00t!

-chris
(no, I'm not joking that people just email it in plain text, it's not
a "password" it's a 'stronger checksum' than 16bit CRC, for bgp at
least)

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Apr 2011 07:43:45 -0400

>>>>> "Christopher" == Christopher Morrow <[email-masked]> writes:

    Christopher> On Wed, Apr 6, 2011 at 3:18 PM, Sam Hartman <[email-masked]> wrote:
    >> From an operational standpoint is it acceptable for us to use
    >> assume that the preshared keys we have are reasonably strong?

    Christopher> why are you injecting your ideas of password strength
    Christopher> into the standard? does it matter if I have 1 char for
    Christopher> a passwd or 15 non-alpha mixedup jumbles? (aside from 1
    Christopher> char is dumb because it's ... 1char)

I'm actually arguing that we should not inject ideas of password
strength.

The reason one might want to inject ideas of password strength is that
there are two possible sets of security technologies.

The first is a traditional challenge/response mechanism.  We know how to
do that.  The drawback is that it has offline dictionary attack
potential.  That means an attacker can (under certain
circumstances--depends on the protocol) capture material that allows the
attacker to mount a dictionary attack against the key on the attacker's
hardware without interactions with the router.

There are other systems that fall into this basic category.

The other class is PAKE systems.
They have stronger dictionary attack resistance, but have traditionally
had IPR and other process problems.
The IPR situation *may* get easier later this year.

Dan proposes that PAKE be a requirement for our key management protocol.
I don't think that is necessary.

---

From: Russ Housley <[email-masked]>
Date: Thu, 7 Apr 2011 10:00:23 -0400

Dan:

That is exactly my point.  The key rollover is the thing we need to focus on right now.  This is the whole point of the key-table draft.  Procedures similar to the ones in TCP-AO can be used with the key-table to seamlessly roll from one key to the next.  This ability will allow strong keys to be manually installed, used, and removed in a straightforward manner.

Then, we can go to work on an automated protocol to populate the key-table with strong keys.

My discussions with several people that build and operate routers leads me to believe that this is a reasonable way forward.  It provides a common model for key management across all routing protocols, and it avoids the designing of integrated key management for each routing protocol.

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 Apr 2011 12:20:40 -0400

On Thu, Apr 7, 2011 at 7:43 AM, Sam Hartman <[email-masked]> wrote:
>    >>
>    >>
>    >> From an operational standpoint is it acceptable for us to use
>    >> assume that the preshared keys we have are reasonably strong?
>

good. this I agree with.

> I don't think that is necessary.

I don't think it's super helpful either.

-chris

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 7 Apr 2011 09:53:28 -0700 (PDT)

Hello,

>> I'm actually arguing that we should not inject ideas of password

  If the use of this credential opens the protocol up to attack then
why is discussion of this topic something to argue _against_?

>> hardware without interactions with the router.

  Right!

>> The IPR situation *may* get easier later this year.

  Right!

>> I don't think that is necessary.

  Now hold on a second. What I proposed was we not just blindly say
"let's use IKE(v2)". There seems to be a desire these days to grab a
tool and use it without taking the time to decide whether its use is
appropriate. Just because I have a screwdriver within arms reach doesn't
mean it's the best tool to use to drive a nail.

> I don't think it's super helpful either.

  What an interesting statement. What do you value in a key management
protocol if resistance to attack is not "super helpful"?

  Dan.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 Apr 2011 20:11:06 +0200

> protocol if resistance to attack is not "super helpful"?

i don't want a key management protocol.

today I can not change keys on sessions, all I want is a simple (and
again, this may be just implementation details for vendors to agree
upon) 'add new key to config, devices work until they fail hashes,
cycle on keys until they work or the session fails, lock on a new key
if hashes start working with that new key'

permit me to change keys sanely and at a rate that works for me.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Apr 2011 14:50:55 -0400

>>>>> "Christopher" == Christopher Morrow <[email-masked]> writes:

    Christopher> today I can not change keys on sessions, all I want is
    Christopher> a simple (and again, this may be just implementation
    Christopher> details for vendors to agree upon) 'add new key to
    Christopher> config, devices work until they fail hashes, cycle on
    Christopher> keys until they work or the session fails, lock on a
    Christopher> new key if hashes start working with that new key'

Hi.
Draft-ietf-karp-crypto-table-00 and draft-ietf-karp-ops-model together
are intended to give you this.
(The ops model goes beyond that; for the purposes of this discussion
feel free to not focus on the parts of the document beyond the
interactions with the key table.)
If you get a chance it would be really helpful if you could take a look
and 

1) see if we're on the right track

2) Do you see any gaps left

Any input you could provide would be greatly appreciated.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 Apr 2011 15:12:27 -0400

> If you get a chance it would be really helpful if you could take a look

I will attempt to read/comment, thanks!

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 Apr 2011 23:38:22 -0400

On Thu, Apr 7, 2011 at 3:12 PM, Christopher Morrow
<[email-masked]> wrote:
> draft-ietf-karp-ops-model

morrowc@host: rfc-editor/ids-text-only$ ls draft-ietf-karp*
draft-ietf-karp-crypto-key-table-00.txt
draft-ietf-karp-crypto-key-table-00.txt.p7s
draft-ietf-karp-design-guide-02.txt
draft-ietf-karp-design-guide-02.txt.p7s
draft-ietf-karp-ospf-analysis-00.txt
draft-ietf-karp-ospf-analysis-00.txt.p7s
draft-ietf-karp-threats-reqs-01.txt
draft-ietf-karp-threats-reqs-01.xml

hrm, no ops-model?

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 8 Apr 2011 00:11:00 -0400

> draft-ietf-karp-threats-reqs-01.xml

a kind reader notes it was posted today, or appeared in the repo today...

---

From: [email-masked]
Date: Mon, 11 Apr 2011 17:39:48 +0800

Hi Dan,

Surely we can use IKEv2 as KMP, but with some extensions to support 
routing protocols, please refer to my draft "Automated Security 
Association Management for Routing Protocols" (
http://tools.ietf.org/html/draft-liang-karp-auto-sa-management-rp-01), 
especially Section 3.1.

While one big concern is, do we really need to reply on IPsec, which seems 
clumsy? I think a light KMP for routing protocols is better.

Cheers,
Ellen (Xiaoping) Liang

2011-04-04 06:22

  Hello,

  regards,

  Dan.

--------------------------------------------------------
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: [email-masked]
Date: Mon, 11 Apr 2011 17:56:47 +0800

Hi Sam,

IKEv2 is a very good KMP in my eye. And just as you said, "we should start 
from IKEv2", that's what I have done. Please read my draft  "Automated 
Security Association Management for Routing Protocols" (
http://tools.ietf.org/html/draft-liang-karp-auto-sa-management-rp-01), 
especially Section 3.1. With enough extensions, IKEv2 can serve routing 
protocols in one-to-one message transaction type. As to routing protocols 
in one-to-many message transaction type, your proposal MRKMP and G-IKEv2 
proposed by Aldous Yeung, et. al. seem possible solutions. 

But I prefer a light KMP, not a KMP relied on IPsec. So I just think 
about...could we design a KMP which doesn't need IPsec? What's your 
opinion? Do you think it is a good idea? 

I really like the key table idea (
http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/), and 
got an idea that extended IKEv2 based on key table makes a light KMP for 
routing protocols.

Would like to hear from you on this topic ^_^

Cheers,
Ellen (Xiaoping) Liang

Sam Hartman <[email-masked]> 
发件人:  [email-masked]
2011-04-07 03:23

收件人
"Dan Harkins" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
[karp] OUr own KMP based on IKEv2

These are my thoughts.

---

From: [email-masked]
Date: Mon, 11 Apr 2011 18:04:38 +0800

I'm thinking a light G-IKEv2 without living in IPsec...^_^ 

Cheers,
Ellen (Xiaoping) Liang

2011-04-07 08:29

> protocol has DOI in its name not withstanding.)

Actually, the G-IKEv2 protocol noted above doesn't have DOI in it's name 
... it's titled "Group Key Management using IKEv2". 

> IPsec-specific assumptions scattered throughout the draft.

It is not intended to be IPsec-specific, although currently only supports 
IPsec. Without a careful read the fact that there is ample namespace 
available for passing non-IPsec policy probably isn't obvious. And the 
mechanism for passing keying material is entirely unrelated to IPsec. 
G-IKEv2 would simply need to define a new GSA TEK Payload type for OSPF, 
IS-IS, PIM, etc. An example of what the GSA TEK payload would like can be 
found in <http://tools.ietf.org/html/draft-weis-gdoi-mac-tek-02>, although 
this I-D is meant for GDOI not G-IKEv2 so it's just an example.

Correct, it does not.

Brian