Subject: [karp] Why automatic key management

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Apr 2010 07:20:08 -0700

I promised to provide some text. Here it is:

The use of automatic key management mechanisms offers a number of
benefits over manual keying. First, it provides fresh traffic keying
material for each session, thus helping to prevent a number of attacks
such as inter-connection replay and two-time pads. Second, it allows
for the negotiation of algorithms, modes, and parameters, thus
providing interoperability between endpoints with disparate
capabilities and configurations. This second point is especially
important because it enables incremental deployment of endpoints with
new capabilities while retaining backward compatibility.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Sat, 03 Apr 2010 15:31:08 -0700

Hi, Eric (et al.),

It's worth distinguishing between aspects below that can potentially be
built off of existing negotiation of a stateful protocol (e.g., deriving
per-session keys from persistent keys), vs those that are necessarily
negotiated using other information (e.g., parameters).

E.g., TCP-AO achieves the former using information TCP already
coordinates, but does not address the latter.

Joe

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

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 3 Apr 2010 16:32:43 -0700

Hi Joe,

It is the same for the Keytables draft -> draft-polk-saag-rtg-auth-keytable.

One major additional advantages of Automatic Key Management over the
Manual case is the administrative overhead + more vulnerability
vectors.

I however agree if we use the Polk draft defined, where we have
different identity keys and traffic keys we may be able to state some
of the advantages mentioned.

Thanks,
Vishwas

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Apr 2010 16:37:31 -0700

> Manual case is the administrative overhead + more vulnerability

I don't understand what this means. In what way is the administrative overhead
or vulnerability vectors less?

-Ekr

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 3 Apr 2010 16:54:04 -0700

Manual Keying requires more administrative overhead of actually
configuring/ changing the Keys etc, which can be done automatically
using automatic keying.

Vulnerabilities due to factors like the channel to change keys from
administrator may not be as sucure. Plus administrator knowing/
configuring the actual traffic keys means it is also now dependent of
the operator.

-Vishwas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 03 Apr 2010 19:55:37 -0400

One of the things I have found confusing in various discussions is that 
"automated key management" is sometimes used to mena various 
combinations of three things:
1) Deriving session keys from long term keys
2) Automated negotiation of session parameters, and possibly key 
derivation parameters, between two (or N?) parties
3) Automated distribution and management of the master keys and 
parameters in an appropriately secure fashion (kdcs, certificates, etc.)

Unfortunately, in writing the charter we did not specify what 
combinations of these we wish to tackle.  It seems likely that the set 
may not even be the same for all cases.

Yours,
Joel

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Apr 2010 16:56:40 -0700

> configuring/ changing the Keys etc, which can be done automatically

I don't agree with this claim, since (1) people typically don't change their
manual keys often at all (2) you still have overhead if you want to
change the long-term keys, which is what happens if, for instance,
an employee leaves.

-Ekr

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 3 Apr 2010 17:16:40 -0700

Ekr,

If Manual Keys are not changed it is a clear vulnerability that is
introduced. Then this is an even bigger issue with manual keying.

If however the manual keys are changed by administrator it leads to
administrative overhead.

There is still overhead of changing long-term keys if we use
Keytables. It however would not be the issue if we were using a DH or
EC-DH.

I guess from the discussion as well as mails from Joel it is clear to
probably define what we mean by "Automatic Key Management". Once we
have that clear we can define the positives/ negatives of a compared
to the other.

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 3 Apr 2010 17:19:32 -0700

Hi Joel,

I vehemently concur with you.

The issues are well known of each mechanism are well known. Its just
that we need to decide what we need to tackle in KARP.

Thanks,
Vishwas

On Sat, Apr 3, 2010 at 4:55 PM, Joel M. Halpern <[email-masked]> wrote:
> "automated key management" is sometimes used to mena various combinations of
> three things:
> 2) Automated negotiation of session parameters, and possibly key derivation
> parameters, between two (or N?) parties
> 3) Automated distribution and management of the master keys and parameters
> in an appropriately secure fashion (kdcs, certificates, etc.)
>
> Unfortunately, in writing the charter we did not specify what combinations
> of these we wish to tackle.  It seems likely that the set may not even be
> the same for all cases.
>
> Yours,
> Joel
>
>
> Vishwas Manral wrote:
>>
>> Hi Joe,
>>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Apr 2010 17:53:05 -0700

> introduced. Then this is an even bigger issue with manual keying.

That's not at all obvious.

For instance, while TCP-AO routinely changes traffic keys, it would
be equally secure to use the same traffic (MAC) key all the time and
instead include the data used to seed the traffic keys in the MAC.

If you're going to make claims of security for mechanism A versus
mechanism B you really need to explain what threats you think you're
protecting against.

> Keytables. It however would not be the issue if we were using a DH or

Huh?

I really have no idea what you're talking about here. DH doesn't (for instance)
relieve you of the need to change long-term authentication keys upon key
compromise.

-Ekr

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 3 Apr 2010 18:11:12 -0700

Hi Ekr,

> mechanism B you really need to explain what threats you think you're
Manual Keys that are used as Traffic Keys in a lot of cases (all RP's
right now) and not changing them (which you seem to say is how it
usually is) in cases I discussed is a big security issue.

Like I said earlier what you are saying is new vulnerabilities we are
discovering. Like Joel said we are using one term for the different
mechanisms, so any statement made needs to be fully qualified.

Thanks,
Vishwas

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Apr 2010 18:14:26 -0700

> usually is) in cases I discussed is a big security issue.

I don't agree, for reasons that I've gone into in quite a bit of detail here:

http://www.educatedguesswork.org/2010/03/against_rekeying.html

Rather than just asserting that not changing keys is insecure, it
would be useful
it you would actually explain what you believe the security issues to be.

> discovering.

Again, I have no idea what you are talking about. What new vulnerabilities.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Sun, 04 Apr 2010 17:47:03 -0700

> Manual case is the administrative overhead + more vulnerability

The term "automatic key management" is vague.

There are different aspects of key management, all of which are 'automatic':

	- negotiation of new keying material for an association

	- negotiation of parameters for an association
	(algorithms, selecting active key from existing ones, etc.)

	- coordinating parameter changes during an association
	(parameters negotiated, as well as additional state such
	as sequence nums [when not in the base protocol], etc.)

It's difficult to understand the advantages unless we understand which
of these mechanisms we're talking about.

Joe

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 5 Apr 2010 00:37:51 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Sunday, April 04, 2010 5:47 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: [karp] Why automatic key management

It's difficult to understand the advantages unless we understand which of these mechanisms we're talking about.

Joe

=====
If I don't over simplify, Can I say RP's need a non-manual "re-keyable AUTH key". The auto key management which is required must have
  - A secure way of mutual authentication mechanism to reach "re-keyable AUTH key"
       - DH provides that secure channel 
       - Either public key/certificate mechanism or some other form of mutual auth-mechanism to authenticate peers before reaching to final "re-keyable AUTH key"
       - Negotiation of parameters for the final association
       - Re-key capability based on life-time of the key

These are the minimal set. 

Thanks,
Uma

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 5 Apr 2010 00:49:18 -0400

Hi Joel,

>>> 3) Automated distribution and management of the master keys and parameters in an appropriately secure fashion (kdcs, certificates, etc.)

I didn't understand the distribution part. All participating parties must authenticate and compute common keys. I am missing some thing. Why distribution ?

Thanks,
Uma

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Saturday, April 03, 2010 4:56 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: [karp] Why automatic key management

One of the things I have found confusing in various discussions is that "automated key management" is sometimes used to mena various combinations of three things:
1) Deriving session keys from long term keys
2) Automated negotiation of session parameters, and possibly key derivation parameters, between two (or N?) parties
3) Automated distribution and management of the master keys and parameters in an appropriately secure fashion (kdcs, certificates, etc.)

Unfortunately, in writing the charter we did not specify what combinations of these we wish to tackle.  It seems likely that the set may not even be the same for all cases.

Yours,
Joel

Vishwas Manral wrote:
>> It's worth distinguishing between aspects below that can potentially 
>> be built off of existing negotiation of a stateful protocol (e.g., 
>> deriving per-session keys from persistent keys), vs those that are 
>> necessarily negotiated using other information (e.g., parameters).
>>
>>> material for each session, thus helping to prevent a number of 
>>> attacks such as inter-connection replay and two-time pads. Second, 
>>> it allows for the negotiation of algorithms, modes, and parameters, 
>>> thus providing interoperability between endpoints with disparate 
>>> important because it enables incremental deployment of endpoints 
>>> with new capabilities while retaining backward compatibility.
>>>
>>> -Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 4 Apr 2010 21:55:49 -0700

I'm not sure I agree with any of this. What's wrong with a manually
shared long-term key
used to authenticate a strong key exchange mechanism, such as SRP?

-Ekr

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 5 Apr 2010 01:19:50 -0400

I'm not sure I agree with any of this. What's wrong with a manually shared long-term key used to authenticate a strong key exchange mechanism, such as SRP?

-Ekr
===

What I said is applicable, if we want to avoid this "manually shared long-term key".  I guess you are talking about EAP/TLS with SRP?? Server has to know all client passwords. In the worst case, this translates to everybody has to remember all other's passwords (Eg: IGP LAN scenarios - we don't know who is DR/DIS brfore hand).

Thanks,
Uma

> If I don't over simplify, Can I say RP's need a non-manual "re-keyable 
> AUTH key". The auto key management which is required must have

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 4 Apr 2010 22:53:02 -0700

> What I said is applicable, if we want to avoid this "manually shared long-term key".

It's not clear we want to avoid this. My impression is that in fact the RTG area
intended to continue using manually managed long-term keys more or less
indefinitely.

> I guess you are talking about EAP/TLS with SRP??

I'm not talking about either EAP or TLS. SRP is a generic technique.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Apr 2010 08:07:30 -0700

Uma Chunduri wrote:
> If I don't over simplify, Can I say RP's need a non-manual "re-keyable AUTH key". 

You really need to explain what the purpose of this mechanism is - key
distribution, parameter negotiation, or both.

Joe

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 5 Apr 2010 11:25:51 -0400

> If I don't over simplify, Can I say RP's need a non-manual "re-keyable AUTH key". 

You really need to explain what the purpose of this mechanism is - key distribution, parameter negotiation, or both.

Joe
====
Authenticated common key mechanism (no distribution with re-key capability) is must and I see parameter negotiation is only a good choice for RP's requirements.

Thanks,
Uma

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 05 Apr 2010 11:34:21 -0400

At the BoF, a series of points were made, and not disputed.
1) Operators do not change the keys used their routing protocols.   (A 
little independent checking confirmed that this can be treated as true. 
  I am sure some operator somewhere has changed the keys, but for all 
practical purposes, they don't do this.)
2) Having the same key, set by the operation staff, visible to the 
operation, and never changing is considered a significant security risk.

You seem to be disputing point 2.
(This was discussed during chartering.  But given the concerns 
expressed, it seems at least worth having a discussion explicitly.)

There were several threats mentioned that were relevant to point 2.
Security folks did mention that in general there is a high risk of 
compromise with keys that never change.  (I understand that the common 
practice of forcing users to change passwords every 90 days is probably 
not productive.  But not changing critical infrastructure passwords does 
seem to be a risk.)
There was also concern expressed about the fact that when a disgruntled 
operations employee leaves, he walks out with the security keys.

At the very least, it seems that it needs to be tractable for the 
operator to change the keys when they want to.  Currently it is 
intractable.
Beyond that, I find myself in the situation of listening to EKR assesrt 
that there is no problem, and a number of other folks assert that there 
is a problem, and describe some threats.

We have a threats document.  Rather than debate assertions, may I ask 
that folks help get a clear description of the threats into the threats 
document.  Then we can debate substantive content.  (For example, does 
the use of master keying and generated session keys reduce the threat or 
not?  Without a description, it seems hard to have the discussion.)  At 
which point Brian and I can try to figure out if there is rough 
consensus or complete confusion.

Yours,
Joel

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 5 Apr 2010 08:59:26 -0700

On Mon, Apr 5, 2010 at 8:34 AM, Joel M. Halpern <[email-masked]> wrote:
> little independent checking confirmed that this can be treated as true.  I
> am sure some operator somewhere has changed the keys, but for all practical
> purposes, they don't do this.)
> (This was discussed during chartering.  But given the concerns expressed, it
> seems at least worth having a discussion explicitly.)

You're gluing a bunch of different issues together here.

The issue isn't the long term use of the key but rather it's
visibility to the operations
staff. On the other hand, it's fairly routine to run large Web sites with keys
that are visible to operators, so I'm not sure how serious this actually
is.

> compromise with keys that never change.

Well, security folks may claim this but for reasons I've gone into ad
nauseum, I think it's mostly bogus.

> (I understand that the common
> practice of forcing users to change passwords every 90 days is probably not
> productive.  But not changing critical infrastructure passwords does seem to
> be a risk.)

Why? I have yet to see any convincing security analysis that supports this.

> operations employee leaves, he walks out with the security keys.

Yes, but this is something you do when you need to, not routinely.

> At the very least, it seems that it needs to be tractable for the operator
> to change the keys when they want to.  Currently it is intractable.

Sure.

> We have a threats document.  Rather than debate assertions, may I ask that
> folks help get a clear description of the threats into the threats document.
>  Then we can debate substantive content.  (For example, does the use of
> master keying and generated session keys reduce the threat or not?  Without
> a description, it seems hard to have the discussion.)  At which point Brian
> and I can try to figure out if there is rough consensus or complete
> confusion.

I've already gone into this in quite a bit of detail both in my
original comments
on the threats document and here:
http://www.educatedguesswork.org/2010/03/against_rekeying.html

I'd certainly be interested to here counterarguments.

-Ekr

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 5 Apr 2010 14:11:51 -0400

> that folks help get a clear description of the threats into the threats document.
>  Then we can debate substantive content.  (For example, does the use 
> of master keying and generated session keys reduce the threat or not?  
> Without a description, it seems hard to have the discussion.)  At 

I've already gone into this in quite a bit of detail both in my original comments on the threats document and here:
http://www.educatedguesswork.org/2010/03/against_rekeying.html

-Ekr

====

It's good analysis why re-key is not required and applicable in certain scenarios. But, there are still some "if"s. It all depends on how you get to the final keys, what algorithms and auth mechanisms used to get there. I don't think generalizing this is a good idea. Imagine password based authentication with AKMs, non-aes cipher/auth algos and non-public key based auth methods usage to get to final keys with out re-key  capability (we almost come back to where we are now). 

Any ways, this is a secondary problem; and if one doesn't want re-key that's fine but that infra should be considered even as last item here for RP's problem at hand. 

Thanks,
Uma

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 5 Apr 2010 11:15:54 -0700

I really have no idea what you're talking about here.

I've provided both a fairly thorough analysis *and* proposed text. If
there is something
you think is incorrect about either of those, please be specific about
what you think
it shoudl say.

-Ekr