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

From: George Gross <[email-masked]>
Date: Fri, 29 Aug 2003 06:30:34 -0400 (EDT)

Hi Hugh,

	The following issue is dangling from an e-mail I had sent to the MSEC list
on July 4th, and there was no discussion of it subsequently. So, to avoid it being
lost in the weeds, I decided to revive it, and tag it similar to the other comments I've
noted wrt/ GSAKMP. Its been about 3 weeks since I sent those e-mails. When addressing them,
please reply to the list using the same subject line as the original e-mail so it is
feasible to track the thread in the mail archive. Please do not simply re-issue the
v04 draft with changes, as it would be best to have discussion on this list first.

thank you,

	George

P.S. this e-mail is a resend, as it never made to the MSEC mail archive
(or back to my own e-mail address).  My apologies if from your mailbox
perspective it is duplicate of the one I sent yesterday.

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.

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).

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

---

From: "Andrea Colegrove" <[email-masked]>
Date: Fri, 29 Aug 2003 11:01:34 -0400

George,
    I am afraid that I cannot agree with the suggestion on the RTJ.

    The strength and choice of mechanisms for group keys must be consistent
with every key download sent to each member.  To vary this would destroy the
integrity of the protection of group data.  It is inconsistent to decide to
download the information in algorithm SUPERSTRONG for one join and in DES
for the next, because of what is supported by the potential member.  If the
potential member cannot support SUPERSTRONG, then that member doesn't have
the necessary mechanisms to support the group SA and thus should not be in
the group.
    Knowledge of the existence of a group and its "address" is obtained in
some sort of group announcement.  It is not any more of an operational
problem to obtain initial mechanism support requirements in this manner as
well.

--- Andrea

----- Original Message -----
From: "George Gross" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 29, 2003 6:30 AM
Subject: [MSEC] GSAKMP issue 24: RTJ should include Key Download KEK
algorithm, mode, key length

---

From: George Gross <[email-masked]>
Date: Fri, 29 Aug 2003 10:05:23 -0400 (EDT)

Hi Andrea,

On Fri, 29 Aug 2003, Andrea Colegrove wrote:

> integrity of the protection of group data.

No, the GCKS always has the right to refuse membership if the asserted Key
Download KEK algorithm/mode/key length does not align with group policy.
See below for additional considerations and configurations that GSAKMP
must support.

>  It is inconsistent to decide to
> for the next, because of what is supported by the potential member.

Not having this mechanism in the RTJ will hardwire a particular group
policy decision into the GSAKMP protocol. By adding this information to
the RTJ, we are allowing hetrogenous group memberships as new versions of
the protocol and algorithms arrive in the field. It is an unreasonable
migration obstacle for the protocol to expect a flash cut of the
membership to newer versions. For example, if AES-128 is the norm for
version 1, and version 2 also supported AES-192, and local group policy
allowed it, there is no reason to deny membership for version 1 endpoints
using AES-128.

> If the

As noted above, the GCKS passes judgement on the RTJ. If it denies
membership, it would send a NACK.

> some sort of group announcement.

The "some sort of group announcement"  is an example of unspecified
information that will cripple inter-operability. Every vendor who
implements GSAKMP is gonna roll their own "group announcement" mechanism?
That does not foster inter-operability, but if you are unable to
standardize that mechanism as a protocol then it is incumbent on the
GSAKMP specification to:

1) exactly prescribe what information the group announcement must
contain and the valid values for those parameters, including the MUST
implement values.

2) Specify that the RTJ in a vendor-independent way tell the GCKS what the
candidate member heard in that vendor-specific group announcement

In a multi-vendor Internet, you can not make GSAKMP dependent on knowledge
of an unspecified and non-standardized group announcement.

If we are unable to standardize the group announcement, then the RTJ must
standardize the information extracted from the vendor-specific group
announcement.

In other words, given:

1) a group announcement by vendor A who openly publishes their spec,

2) group member using GSAKMP from vendor B, that understands vendor A's
group announcement,

3) and GCKS using GSAKMP from vendor C that doesn't implement vendor A's
spec for group announcments.

They should all be able to work together. The network operator should not
have to deploy vendor C's group announcment mechanism, nor should they
expect all group members to be from vendor C. They just need to be able to
configure the GCKS so that its view of the group announcement matches what
vendor A advertises even if the GCKS couldn't understand the bits on the
wire of that vendor A advertisement's encoding. And the GCKS must be able
to inter-operate with vendor B endpoints, and vendor A's, and vendor
D's....

>  It is not any more of an operational

As seen above, there are clearly issues about multiple versions and
multiple vendors deploying GSAKMP. These are real issues, and they have
the potential of making GSAKMP unusable in the field. In my mind, this is
a litmus test for the GSAKMP co-authors to alter the specification to meet
the higher bar required for a proposed standard.

	George

---

From: "Andrea Colegrove" <[email-masked]>
Date: Fri, 29 Aug 2003 13:01:55 -0400

George,
> Download KEK algorithm/mode/key length does not align with group policy.

What does this accomplish?

The RTJ itself has security requirements on it.  A GCKS should not even
attempt to process something that is not of sufficient caliber.  So even
before RTJ, the potential member must have some knowledge of the group.  If
we look at Tunnelled GSAKMP, we see add some negotiation capability before
Key Download, but even so, the member still needs to know what the group is
about:  address, application, etc.  This is done through web interfaces,
SAP, etc.

Whether the key download is not interpretable by the potential member or
whether the GCKS NACKs the member is irrelevant from the perspective of the
new member. The bottom line for the GCKS:  The policy of a group is not
negotiable, unless with each negotiation, you query the existing group
membership to see if anyone wants to opt out.

> allowed it, there is no reason to deny membership for version 1 endpoints

If a group's policy allowed it -- then yes.  One of the nice things about
flexible specification languages such as ASN.1 is that it allows flexibility
of group policy to

KeyDownloadMech (or whatever)::= CHOICE {
    aES128           [0]     AES128,
    aES192           [1]     AES192
}

This does not hardwire it to a version of GSAKMP -- the announced mechanisms
can be the suite defined as Suite 1, a set of algorithms independent of any
suite, or a new Suite 2 defined independently.

> implements GSAKMP is gonna roll their own "group announcement" mechanism?
Someone advertising a group will indicate what the group is about, where it
is to be found (addresses, applications, etc.), what security management
(and parameter choices), etc.  Security management is only a part of the
group application problem.  See SIP, SAP, etc for more info here.

> the potential of making GSAKMP unusable in the field.

Once again, there is a difference between a version of a protocol and the
mechanisms that a particular implementation may choose to support.  Yes,
there needs to be a MUST implement set for interoperability testing (we have
that in Suite 1), but support of different mechanisms does not mean
different protocol versions.

--- Andrea