Subject: [MSEC] Next GDOI draft

From: Brian Weis <[email-masked]>
Date: Tue, 18 Jun 2002 14:57:04 -0700

This is a heads up that we will be submitting a new GDOI draft soon with
some minor changes. It is necessitated by a request from the Steve
Bellovin that we improve the Security Considerations section before
submitting it to the IESG. 

In the meantime we've discovered a few small issues which need to be
corrected; I'll forbear from describing them here, but could send them
to the list if requested.

One issue does warrant some discussion on this list. It has primarily to
do with expelling group members when a group key management algorithm
(e.g., LKH) is used with a KEK. It is also somewhat of an issue when a
KEK is used alone.

Recall that a GROUPKEY-PUSH message is a single exchange sent to all
group members (probably via multicast). It looks like this:

	Member                               GCKS or Delegate
        ------                               ----------------

                  <---- HDR*, SEQ, SA, KD, [CERT,] SIG

The entire message (following the *) is encrypted under the "current"
KEK which is held by all group members. The SA payload may contain
policy for a "new" KEK which will replace the existing KEK, and this
replacement begins with the next GROUPKEY-PUSH message. If the SA
payload has new KEK policy, then the KD payload will contain the new KEK
keys. This is most likely the case where an LKH group membership key
tree is used, so the KD payload will have several sets of key arrays
which work together to provide a new KEK to group members who have not
been expelled from the group. [See RFC 2627 for details.]

Notice that the expelled group member will not be able to read the new
KEK (that's the main property of a group management algorithm), but
because he has possession of the "current" KEK and can decrypt and read
the rest of the message.

Now if someone has taken the trouble to expel one or more group members
they'll also want to change the TEK SAs (e.g., IPSec SAs) and keys so
that the expelled member can no longer participate in the group. For
efficiency reasons it should be possible to send out the new TEK SAs in
the same GROUPKEY-PUSH message in which the KEK is changed. The SA and
KD payloads support this today.

But here's the problem: Since the expelled group member has the
"current" KEK and can read the entire message, he will be able to read
the new TEK SAs and keys and thus won't be expelled from the group until
the NEXT GROUPKEY-PUSH message is sent by the GCKS. The next message
will be the first use of the new KEK.

Here are some possibilities to resolve the issue in the draft:

Solution 1: The simplest fix for this problem is to disallow sending of
any TEK SAs in the same GROUPKEY-PUSH message as a KEK SA.
Unfortunately, this disallows any possibility of efficient rekeys of
group policy. This does have the advantage of being the most minimal
change to the draft as it would simply add some MUST NOT statements.

Solution 2: Leave the KD payload intact. That is, allow it to contain
both the KEK and TEK keys. But require the TEK portion of the KD payload
to be super-encrypted with the new KEK. This maintains efficiency, but
requires extra processing to that portion of the KD payload which is
super-encrypted. This is a  minimal (but subtle) change to the
GROUPKEY-PUSH protocol. However it does add substantial complexity to
the construction and processing of the KD payload.

Solution 3: Allow two KD payloads in the GROUPKEY-PUSH message, one
which would contain the KEK keys. The other would the TEK keys and be
super-encrypted with the new KEK. This is the most change to the draft,
but does provide the desired efficiency and is the cleanest overall
design.

I'd be interested at hearing opinions on the above solutions and/or
alternate solutions.

Thanks,
Brian

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

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

---

From: Brian Weis <[email-masked]>
Date: Wed, 19 Jun 2002 09:44:39 -0700

Further clarification is needed since I wasn't very clear how Solutions
2 and 3 below would be implemented.

As currently specified the entire rekey message is protected under KEK.
The first operation of any group member is to decrypt the message with
KEK. Then as part of KD payload processing the group member determines
the new key protecting rekey messages (KEK') from the LKH update arrays. 

The new proposed processing (for solutions 2 and 3) would be for the
group member to use KEK' to decrypt the TEK keys in the KD payload. In
this way, a group member who had been removed from the group would not
be able to gain the next set of TEK keys.

This is a reasonable thing to do. But I'd like to get a sense from the
working group as to how comfortable they feel about making a change like
this after the protocol has finished working group last call.

The difference between solutions 2 and 3 has to do with payload
processing. Solution 2 does not change the message structure, but may be
more difficult for an implementation.

Thanks,
Brian

---

From: Mark Baugher <[email-masked]>
Date: Thu, 20 Jun 2002 10:07:35 -0700

Hi All,

>group members (probably via multicast). It looks like this:

I favor this solution although it is arguably broken.  The
reason I favor a broken solution is that we don't yet have
enough implementation experience.  We discussed this problem
at length at the start of WG Last Call.  There is no IETF requirement
that we have interoperable implementations for a Proposed Standard.
Thanks to Brian and Lakshminath, we did have interoperable
implementations for the PULL (GKM Registration) exchange.  I recall
that you discovered a problem with the PUSH (GKM Rekey) message as
soon as you implemented it.  I expect that we'll discover more as
we get more implementation experience with LKH (e.g. two
interoperable implementations).

I'm afraid that too many last-minute design decisions will
result in problems.  I also think that GDOI is very useful
without LKH-like function.  I think this is okay for the
Proposed Standard.

regards, Mark

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 21 Jun 2002 10:58:59 -0400

Brian,

Would it be possible to keep the SA payload secret (to disallow 
kickedout members from knowing policy changes), if necessary?

cheers,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 21 Jun 2002 11:29:43 -0400

Mark Baugher wrote:

<snip>

 > There is no IETF requirement

Standards rules aside, an interoperability exercise and a protocol 
analysis similar to what Cathy Meadows did for GDOI, will help identity 
problems that we might otherwise overlook.  This applies to LKH and 
similar algorithms, considering everyone has a different take on how to 
implement them.

> without LKH-like function.  I think this is okay for the

I agree with GDOI being useful without LKH scalability, and favor 
leaving it out of the spec and concentrate on getting the PUSH message 
right.

Finally, I must note that Brian has put a lot of work into incorporating 
LKH into the GDOI draft.  We could take one of the following many :-) 
routes:

1) Pull it out and start a separate draft on LKH
...
n) Pull it out and start a separate draft on LKH

n+1) Take the time to do a thorough review.  Many of us implemented it 
at some level.  It is time to put that experience to come up with a 
standard.

cheers,
Lakshminath

PS: n is a large positive integer

---

From: Brian Weis <[email-masked]>
Date: Fri, 21 Jun 2002 08:51:08 -0700

Hi Lakshminath,

It's not really possible to keep the SA_KEK payload secret, because that
policy is needed in order for a group member to use the KEK (including
any LKH arrays) in the KD payload. :-)

But I think you were asking about the SA_TEK payloads containing policy
for the IPSec SAs. We don't have any mechanism today for keeping
expelled group members from viewing the SA_TEK payloads. They will have
access to the KEK which is used to decrypt the entire PUSH message. The
only method I can think of for hiding them from expelled group members
would be to send them in a separate PUSH message following the KEK
change so that they are wholly encrypted under the new KEK.

But I'm not convinced there's much risk to expelled group members from
seeing the policy. The new SA policy is unlikely to change when
replacement SAs are distributed. The new SPI values will be documented
in the SA_TEKs, but then they'll also be in the clear when data traffic
using those SPIs starts flowing too. If a group has a security policy
which says that the policy must be kept secret, that policy can be
easily accommodated by sending the SA_TEKs in a separate PUSH message
from the SA_KEK.

Do you see any other risk?

Thanks,
Brian

---

From: Brian Weis <[email-masked]>
Date: Fri, 21 Jun 2002 08:57:20 -0700

Mark Baugher wrote:

> without LKH-like function.  I think this is okay for the

I need to clarify that Solution 1 does NOT propose removing LKH. It
proposes forcing changes of the LKH KEK to be isolated into its own PUSH
message, which is a very small change to the existing draft. Removing
LKH would be a relatively large change to the draft.

Brian

---

From: Mark Baugher <[email-masked]>
Date: Fri, 21 Jun 2002 09:58:12 -0700

Brian
   I understand that you want to minimize refinement of
LKH in the draft and not eliminate LKH from the draft.

Mark

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 21 Jun 2002 13:39:29 -0400

Brian,

Securing SAKEK or SATEK policy, or the GSPT may be a requirement for 
some applications.

The solution (sending policy twice) could be confusing and must be 
stated either in the PUSH message description, or in the Security 
Considerations section.  Thanks.

best,
Lakshminath

---

From: Mark Baugher <[email-masked]>
Date: Fri, 21 Jun 2002 10:53:18 -0700

hi Lakshminath,

At 01:39 PM 6/21/2002 -0400, Lakshminath Dondeti wrote:
>Brian,
>
>Securing SAKEK or SATEK policy, or the GSPT may be a requirement for some 
>applications.

If we try to solve the security problems of all actual
and potential applications, we'll have a protocol that
is too complex for most applications.  ISAKMP is
complex enough and so is its GDOI.

thanks, Mark

>The solution (sending policy twice) could be confusing and must be stated 
>either in the PUSH message description, or in the Security Considerations 
>section.  Thanks.
>
>best,
>Lakshminath
>
>Brian Weis wrote:
>
>>Hi Lakshminath,

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 21 Jun 2002 14:10:52 -0400

Mark,

I understand that, and my point is it is ok to not support a potential 
security requirement, but that should be made clear in the Security 
Considerations section.

It turns out that GDOI can do it (I think) with an extra PUSH message.

cheers,
Lakshminath

---

From: Brian Weis <[email-masked]>
Date: Fri, 21 Jun 2002 11:06:02 -0700

Hi Lakshminath,

> Securing SAKEK or SATEK policy, or the GSPT may be a requirement for

The only way to secure the SAKEK would be to force all authorized group
members to re-register via a PULL message. We can note this in the
Security Considerations.

> Considerations section.  Thanks.

Just to clarify my point earlier, the no single policy is actually sent
twice -- the KEK keys/policy is just split from the TEK keys/policy.
There are two independent PUSH messages. But I agree that it warrants
discussion in the Security Considerations too.

Thanks,
Brian

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 21 Jun 2002 14:33:57 -0400

First,

It seems that we agree that this is a topic to be covered in the 
Security considerations section.

But, :-) ... please see inline:

> members to re-register via a PULL message. We can note this in the

What if we do a round of rekeying under old policy and another round of 
rekeying with a new policy.  Thus the group switches over to new keys 
first followed immediately by a switch over to new policy (with or 
without a whole new set of keys).  Would that work?

Thus a kicked out member will not know whether the group changed the 
KEK_ALGORITHM or not :-).  Now, I am NOT saying that hiding the 
algorithm name offers any extra protection.

The point is that the SA payload is part of the encrypted portion of the 
PUSH message.  If it is not made clear that evicted members can see it, 
we might add a more important attribute to the payload forgetting that 
it is effectively sent in the clear.

cheers,
Lakshminath

---

From: Mark Baugher <[email-masked]>
Date: Fri, 21 Jun 2002 12:16:35 -0700

hi
   I'm happy with adding this to the security considerations section

thanks, Mark

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 21 Jun 2002 16:33:09 -0400

Brian,

Thanks.  Two complete rekeys it is then :-); I was thinking we could get 
  away with some trick (a flag in the first message indicating that the 
SA will change and is in the next message) to change policy without 
having to resend a whole GKMA array again.

But, doing two complete rekeys will be a much cleaner solution.

cheers,
Lakshminath

Brian Weis wrote:

> Hmmm, that's an interesting idea. But there's obviously potential for
> some group member having the wrong policy since there would be different
> sets of policy valid at different times for the same key! This would be
> similar to changing an IPSec policy for the same key/SPI in the middle
> of its lifetime (e.g., from 3DES/SHA to DES/MD5). It seems a bit
> dangerous.
> 
> But since two rekeys are required, you might as well do two complete
> rekeys (new key/SPI, new policy) to get the desired result. At the end
> of the first rekey the expelled group member knows the policy but not
> the key. At the end of the second rekey, the group member has no
> knowledge of group policy.
> 
> How about if we document that solution in the Security Considerations?
> 
> Thanks,
> Brian
> 
>

---

From: Brian Weis <[email-masked]>
Date: Fri, 21 Jun 2002 13:19:48 -0700

Hi Lakshminath,

Thanks,
Brian