Subject: Re: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK algorithm, mode, key length

From: Hugh Harney <[email-masked]>
Date: Tue, 2 Sep 2003 10:49:22 -0400

George,

Sorry for the delay.

We do plan on answering all your points. Our clock just has a slower 
rate than yours. There has been a lot of travel this summer.

>
> GSAKMP issue 24
>
> Section and relevant text passage:
>
> Section 4.2.1.2, the spec says:
>
> "The Policy Token and Key Download payloads are sent encrypted in the 
> KEK
> generated by the Key Creation payload information using the mechanisms
> defined in the group announcment."
>
> Comment/issue description:
>
> However, the group announcement is done out of band and it is not 
> defined
> within this specification. Yet here it directly impacts what algorithms
> and key lengths one would expect to encounter in the Key Download 
> message.
> This seems to imply you can't connect to the group unless a candidate
> member is privy to some non-standard pre-arranged convention, which is
> overly restrictive and non-interoperable.

The purpose of the announcement was to provide a means for someone to 
specify a security suite other than the security suite 1. This is to 
say that a vendor could define GSAKMP to operate on another set of 
security protocols as long as that vendor specific suite was announced 
or understood.

Since security suite 1 is a MUST in the GSAKMP spec (at least for 
version 1), I see no issues with non-interoperability or over 
restriction. The generic GSAKMP header has the version number of the 
GSAKMP spec. If and when someone writes a version 2 GSAKMP spec, then 
the version 2 GSAKMP will know that the member sending the RTJ is 
sending it in conformance with the version 1 spec.

If your objecting to our suggestion of using an announcement to allow 
people to define the use of vendor specific security suites, then we 
could take that out of the spec.

>
> Suggested issue resolution:
>
> I think that the "mechanisms defined in the group announcement" should 
> also be
> copied as a new set of fields in the Request To Join message. That 
> way, the GCKS
> can accept group members who did not hear the group announcement, or 
> may have heard an
> older version of the group announcement that specified a different KEK 
> algorithm,
> mode, and key length than a more recent version of that announcement.
>
> Further, the protocol spec should mandate at least one algorithm, 
> mode, and key
> length that both GCKS and group members are both required to implement 
> for the KEK.
>
> This seems to be a place where you would say something like:
>
> "...using the mechanisms defined in the group announcement, which are
> required to be identical to the set defined for IKEv2, or the IANA
> registry's current set of algorithms. This includes the same MUST
> implement requirements as IKEv2"
>
> or some words to that effect (wordsmithing TBD).

Are you suggesting negotiable security parameters for the GSAKMP 
protocol on a member by member basis? Or are you just saying that we 
should specify the security suite the member is using to send the RTJ?

Hugh

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Hugh Harney <[email-masked]>
Date: Mon, 22 Sep 2003 17:41:23 -0400

George,

Don't worry all questions will be discussed before 04 is released.

George,

> defined in the group announcement."
>
I think there are two issues being discussed here.

First, announcing the security suite for a group.

I really don't like the idea of having negotiable security suited for 
the registration protocol. The level of security algorithms has to be 
equivalent across the group. (the old your only as secure as your 
weakest link argument). This problem is exacerbated in creating a group 
because all communicating entities do not connect to each other while 
setting up the group key.

Second, specifying a must algorithm for key download.

I agree that we need to pick a MUST algorithm. However, the choice of 
MUST is a bit difficult. The cryptographic requirements for key 
encryption algorithms is a bit different than that required for key 
creation. If we need to specify a MUST we may want to specify RFC 3394 
"Advanced Encryption Standard (AES) Key Wrap Algorithm".

I am a bit worried because 3394 is not in a standard crypto toolkit.

Hugh

---

From: Hugh Harney <[email-masked]>
Date: Mon, 22 Sep 2003 17:44:08 -0400

George,

I just noticed that there is an RFC for using 3DES for key wrapping.

Hugh

---

From: George Gross <[email-masked]>
Date: Mon, 22 Sep 2003 21:21:29 -0400 (EDT)

Hi Hugh,

> Don't worry all questions will be discussed before 04 is released.

looking forward to it, albeit I'll be saturated this week, so my responses
will be congestion controlled....

> setting up the group key.

Let see if I hear your point of view correctly: are you saying that the
selection of a "weak" registration SA encryption protocol could
potentially weaken the integrity of group SA? or a weak group encryption
algorithm for the group SA is the problem you are worried about?

However, I'm concerned about this being too brittle an approach once
deployed into field practice. I'm too tired at the moment to try to sketch
out a scenario where this would occur, but I'm thinking along the lines of
my earlier e-mails that had heterogenous endpoints (multi-vendor,
multi-version, and GDOI/GSAKMP). It seems hard operationally to make a
large-scale multicast group all in lockstep synchronize and sing one
tune...even if it reduces to the "weakest link security" that might be
"good enough" for local group policy if the alternative is incomplete
group connectivity and stranded endpoints.

> Second, specifying a must algorithm for key download.

I infer by context that you are referring to how to key wrap encrypt the
Key Download payload within a Re-key Event Message (e.g. for GTEK or LKH).
Yes, this needs to be nailed down. See observation/comment below about AES
vs. DES.

OTOH, the registration SA could be protected in another method than key
wrap/encryption. The whole Key Download Message (including the Key
Download payload within that message) could be completely encrypted by an
encryption key derived from the Diffie-Hellman secret key material
SKEYSEED, ala IKE-v2 section 2.14.  Is there any reason why one could not
do key derivation here for the GSAKMP registration SA? that would also
require a PRF algorithm spec too...  I notice that the current GSAKMP
policy token draft table 6 only specifies "preplaced key" for key
creation, which I assume means a "pre-shared secret key" between GCKS and
GM, right?

Q: what is the lifetime of the GSAKMP registration SA?

> I am a bit worried because 3394 is not in a standard crypto toolkit.

As you indicated in a subsequent e-mail, informational RFC3217 specifies
triple-DES key wrap. While I'm partial to AES, triple-DES is today's norm,
so I suppose we should point to RFC3217 as the MUST, and RFC3394 as the
SHOULD+.

that said, I've noticed that IKE-v2 section 3.3.4 talks about mandatory
algorithm IDs, and basically says that the management interface must be
flexible enough to configure anything: Diffie-Hellman parameters, key
lengths, various flavors of crypto-suites. Perhaps clone a page from the
IKE-v2 book about how to generally handle this topic in GSAKMP?

br,
	George

---

From: Hugh Harney <[email-masked]>
Date: Tue, 23 Sep 2003 00:14:21 -0400

Hi George,

comments in-line, sorry if it is getting to be a large e-mail.

> will be congestion controlled....

I've got more than a couple of pans on the stove myself.

> algorithm for the group SA is the problem you are worried about?

In order for the group SA to be meaningful, everyone in the group must 
be able to trust that the mechanisms used to set-up and protect the 
group SA. This means that the algorithms used to register the GMs have 
to be equivalent from a security perspective.

Let's take an extreme example: Let's assume that the GO decides that 
the data being protected by the group SA is of highest priority. The GO 
specifies that Security Suite 1 is necessary to join that group. Next, 
If GM A only supports the top tier algorithms for registration, because 
only those algorithms are adiquate, then GM A will use those algorithms 
to connect with the GC/KS. However, GM B doesn't have top tier 
algorithms. GM B negotiates the use of something less than the top tier 
to join the group that GM A is a member of. Then GM B gets access to 
the group SA keys using less than the top tier. That means that an 
adversary would only have to defete the non-top tier algorithms used by 
GM B to get access to the key that GM A is using. Hence, GM A's top 
tier algorithms do not protect it. The security of the group SA keys is 
limited to the protection of the weakest algorithms used.

> group connectivity and stranded endpoints.

I think this is taken care of if we allow a security suite to specify a 
set of equivalent algorithms. Only those algorithms in the security 
suite are acceptable, but any of them are acceptable.

Also, you have to remember that the GO sets the security suite and 
creates the PT based on the data protection requirements of the group. 
There may be cases where people can't join a group. That is a feature 
not a problem. Not everyone should always be allowed to join a group. A 
simple example: I don't want my bank to lock my money up using a 
cardboard box just because that's all they have. My money needs to be 
protected by steel. If the bank can't meet that protection requirement 
then I don't want them protecting my money.
> creation, which I assume means a "pre-shared secret key" between GCKS 

I expect that D-H (or something similar) will be used to create the 
download key. I was pointing out that IKEv2 doesn't do key wrapping. We 
have to make sure we meet the key wrapping requirements.

We use D-H to create the key download keys in GSAKMP. If the PT only 
states pre-placed that needs to be expanded. We do need to support 
pre-placed, but not be limited to only PP.
> Q: what is the lifetime of the GSAKMP registration SA?

I think this is open right now. My thoughts have been to limit the 
lifespan.
> so I suppose we should point to RFC3217 as the MUST, and RFC3394 as the

I need to perk on this. I think I tend to agree. However, 3217 isn't in 
standard toolkits right now. I don't think.
> IKE-v2 book about how to generally handle this topic in GSAKMP?

I'll borrow anything that I can.
>> Hugh
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046

---

From: George Gross <[email-masked]>
Date: Tue, 23 Sep 2003 06:09:38 -0400 (EDT)

Hi Hugh,

	okay, to re-cap what we've discussed/agreed:

1. The RTJ will have a mechanism to select one of a set of proposal
choices offered by the GO in the PT. these would be a set of equivalent
algorithms from the local security policy's point of view. next step would
be to flesh out the details of the proposal parameters choices for the 3
SA types.

2. The Re-key Event message's Key Download payload needs to refer to a
standard key wrap algorithm, at the moment RFC3217 is nominated, though it
is informational not PS. This is sorta still an open issue.

3. The Diffie-Hellman secret computed during registration SA set up will
go through a key derivation to form the encryption key and an
authentication key used on the Key Download message.

4. the registration SA will have a lifetime. no doubt spec'd by the PT?
optionally time based? note that the registration SA would be useful to
leave around for a leave group request from the GM...

5. if using pre-shared keys for the registration SA or rekey SA's key
encryption key applied to the key download, then it would be a good thing
to borrow IKE-v2 verbage (see section 2.15) about picking shared keys with
enough entropy (especially if passwords are being used as the function's
input).

6. There needs to be verbage, akin to what is said in IKE-v2 section
3.3.4, about the GSAKMP management interface should be highly configurable
to specify DH parameters, key lengths, algorithms, etc.

did I leave anything out?

br,
	George

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Tue, 23 Sep 2003 12:10:13 -0400

Does GSAKMP support PSKs (topic of item 5 below)?

Lakshminath

---

From: Hugh Harney <[email-masked]>
Date: Wed, 24 Sep 2003 09:07:27 -0400

Lakshminath,

While it hurts to stretch my mind to envision GSAKMP in a pre-placed 
key mode, I can see the protocol being used to send the PT around along 
with the rekey messages.

Hugh

On Tuesday, Sep 23, 2003, at 12:10 US/Eastern, Lakshminath Dondeti 

Hugh Harney							Sparta, Inc.

---

From: Hugh Harney <[email-masked]>
Date: Wed, 24 Sep 2003 09:25:58 -0400

George,

Here is a quick response. I'm stuck in all day meetings today and 
tomorrow.

> be to flesh out the details of the proposal parameters choices for the 

OK, I can see a mechanism field.

I'm not sure there is a set of proposal parameters for the 3 SAs. Once 
the PT is delivered the specifications of the SAs are set. I'm very 
concerned about making the total group SA balanced.

> is informational not PS. This is sorta still an open issue.

I agree
> authentication key used on the Key Download message.

I agree
> leave around for a leave group request from the GM...

I'm not sure of this. The registration SA is primarily a key download 
SA.

We also have to discuss the "flavors" of group leaves. Management 
messages may not go to the key management system. Events generated by 
management messages we may have to respond to -- loss of trust in a 
group member is one.
> enough entropy (especially if passwords are being used as the 

I can see using GSAKMP to support the passing of PTs, and rekey 
messages. If we use pre-placed KEKs to protect key downloads then I can 
see borrowing IKEv2 prose.

I'm struggling with implementing a ton of optional modes in the spec, 
because I believe we then have to implement them all. I'd rather keep 
it as simple as possible.
> to specify DH parameters, key lengths, algorithms, etc.

Is this really the GO management interface that specifies the content 
in a PT?
> did I leave anything out?

I hope not!!

I'm going to be out of pocket for a couple of days, so e-mail will be 
sparse at best.

cheers

Hugh
Hugh Harney							Sparta, Inc.

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Wed, 24 Sep 2003 14:31:06 -0400

My reference to PSKs is in the context of host authentication; I don't 
mean that we download the registration SA a priori via other means.

Lakshminath

Hugh Harney wrote:

> key mode, I can see the protocol being used to send the PT around 
> along with the rekey messages.
>
> Hugh
>
>
> On Tuesday, Sep 23, 2003, at 12:10 US/Eastern, Lakshminath Dondeti wrote:
>