Subject: RE: [MSEC] Next GDOI draft

From: Luca Venturi <[email-masked]>
Date: Fri, 21 Jun 2002 12:30:41 +0200

I believe that would really be a great effort, but to my mind it is
definitely a better solution to fix the draft according to one of the
solutions 2 or 3. Solution 3 seems to me the most efficient as it is a
cleaner solution to divide the KD payload up into a KEK part and a TEK
part: that would be also easier to implement. 
I see that would be a most change to the draft as it would require a
re-definition of the KD payload, but it if we renounce to the chance of
changing both the TEK and the KEK in the same message, that means not to
take advantage of the properties of LKH algorithm, without which GDOI
loses most of its efficiency, as that would reduce GDOI's potential of
being used in the greatest possible number of contexts. 
Indeed, the only thing to take into account is the computational
overhead introduced by such a modification (although Solution 3 wouldn't
require that much payload processing, after all ...), but in my opinion
this problem is overwhelmed by the benefits GDOI might draw from it.
Best Regards
Luca

---

From: "MICHAEL GERMONY" <[email-masked]>
Date: Mon, 24 Jun 2002 08:23:42 -0400

please add Scott Gribben in the contact info.
639-6641

>>> Lakshminath Dondeti <[email-masked]> 06/21/02 02:33PM >>>
First,

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

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

Brian Weis wrote:

> Hi Lakshminath,
> 
> Lakshminath Dondeti wrote:
> 
>>Brian,
>>
>>Securing SAKEK or SATEK policy, or the GSPT may be a requirement for
>>some applications.
>>
> 
> 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.
> 

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

> 
>>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.
>>
> 
> 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
> 
> 
>>best,
>>Lakshminath
>>
>>Brian Weis wrote:
>>
>>
>>>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
>>>
>>>Lakshminath Dondeti wrote:
>>>
>>>
>>>>Brian,
>>>>
>>>>Would it be possible to keep the SA payload secret (to disallow
>>>>kickedout members from knowing policy changes), if necessary?
>>>>
>>>>cheers,
>>>>Lakshminath
>>>>
>>>>Brian Weis wrote:
>>>>
>>>>
>>>>
>>>>>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
>>>>>
>>>>>Brian Weis wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>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 
>>>>>>
>>>>>>
>>>>>>
>>>>_______________________________________________
>>>>msec mailing list
>>>>[email-masked] 
>>>>http://www.pairlist.net/mailman/listinfo/msec 
>>>>
>>>>
>>_______________________________________________
>>msec mailing list
>>[email-masked] 
>>http://www.pairlist.net/mailman/listinfo/msec 
>>
> 

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

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