[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force
Internet Draft                                   L. Dondeti, T. Hardjono
draft-ietf-msec-secure-feedback-00.txt         Nortel Networks, Verisign
Expires: Dec 2003                                               Jun 2003


Securing Feedback Messages: Secure and Scalable Many-to-one Communication

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference mate-
   rial or to cite them other than as "work in progress".

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.


Abstract

   Members in a secure group may need to communicate to the GCKS to
   Deregister from the group, for SA resynchronization, or to request
   retransmission of a Rekey message. A simple solution is to keep the
   registration SA around, but that comes at the expense of O(n) SA
   maintenance, and storage at the GCKS. Each member is also responsible
   for maintaining an extra SA. We propose an efficient method for mem-
   bers to securely send messages to the GCKS, using the Rekey SA.















L. Dondeti, T. Hardjono                                       [Page 1]


Internet Draft     draft-ietf-msec-secure-feedback-00


                           Table of Contents

1. Introduction to GSA

2. Need for Many-to-one Secure communication in Secure Groups

3. Proposed Solution

3.1. Rekey Message

3.2. Feedback Message

3.3. Integrity Protection of Feedback Message

3.4. Processing at the members

3.5. Processing at the GCKS

4. Security Considerations

5. References

6. Authors' Contact Information








1 Introduction to GSA

   The GKM architecture [1] proposed by MSEC defines three SAs: Regis-
   tration SA, Rekey SA and Data Security SA. These three SAs comprise
   the Group SA (GSA). The Registration SA protects member initializa-
   tion process, and protects the downloading of Rekey and the Data
   Security SAs.  At this point the GCKS uses a one-to-one secure chan-
   nel, protected by the Registration SA, for secure communication.

   The Rekey SA protects Rekey messages, which contain updates to the
   Rekey SA or a new Data Security SA. The Data Security SA protects
   data transmissions to the group.

   For scalable operation, it is inefficient to keep the registration
   SAs alive, especially in large groups. Each registration SA may have
   to be stored and maintained (rekeyed periodically) from the time the
   corresponding member joins the group until it leaves.  This is



L. Dondeti, T. Hardjono                                       [Page 2]


Internet Draft     draft-ietf-msec-secure-feedback-00


   expensive due to the large state storage required and the computation
   and communication overhead due to SA maintenance.

2 Need for many-to-one communication in secure groups

   Secure communication in groups as defined in GKM architecture [1] is
   mostly one-way from the GCKS to the members (sender and receivers),
   and from the sender to the receivers. As noted earlier, the Rekey and
   the Data Security SAs are used to protect these communications.

   But, from time to time members may need to contact the GCKS, for
   example, to request retransmission of a rekey message, for GSA syn-
   chronization, or to Deregister from the group.

3 Proposed solution

   We propose a scalable protocol to send feedback securely using the
   Rekey SA. Note that in most, if not all, group key management algo-
   rithms, the GCKS shares a unique key with each member. For example,
   in LKH, this key corresponds to the leaf node a member is associated
   with. We propose to use the unique key to protect the integrity of
   the feedback message.

   The Sequence number from the lost or the most recently received rekey
   message can be used for replay protection. Such Sequence number use
   for feedback messages, allows efficient implementation at the GCKS.
   Specifically, the GCKS does not need to maintain per-member Sequence
   numbers.

3.1 Rekey message

   Our design of the feedback message is based on GDOI Rekey message
   (although there is no reason to believe that this won't work for
   GSAKMP rekey messages) or GROUPKEY-PUSH message:


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

  * protected by the Rekey SA KEK; Everything after the HDR is encrypted



   The HDR is an ISAKMP header. The SEQ payload contains a monotonically
   increasing sequence number. The SA payload can include one or more
   SAKEK payloads and zero or more SATEK payloads. The KD payload con-
   tains KEKs and TEKs corresponding to SAKEK and SATEK payloads.  The



L. Dondeti, T. Hardjono                                       [Page 3]


Internet Draft     draft-ietf-msec-secure-feedback-00


   SIG payload signs the hash of a message formed by concatenating the
   string "rekey" with the Rekey message (excluding SIG itself). The
   message is encrypted (excluding the HDR) using the group KEK.

3.2 Feedback message


  Member                                        GCKS
  -------                                      ------
  HDR*, SEQ, REQ, AUTH -->

  * protected by the leaf/unique KEK of member;
    Everything between the HDR and the AUTH payload is encrypted



   The HDR is ISAKMP header payload (see RFC2408 [2]) and is formed sim-
   ilar to that in GDOI (see Section 4.5 in [3]). The cookie pair is the
   same as in the recently received Rekey message. The next payload is
   the SEQ payload. The Exchange Type has a value for FEEDBACK-MESSAGE
   (to be assigned a number). Length is computed as specified in
   RFC2408. The rest of the fields are the same as in the received mes-
   sage.

   The SEQ payload contains the SEQ message in the most recently
   received GROUPKEY-PUSH message.

   The REQ payload is new (to be assigned a payload number) and contains
   the Feedback message.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
     ! REQ type      !                  RESERVED2                    !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
     ~                    Request data                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!





   REQ type            value
   --------            -----



L. Dondeti, T. Hardjono                                       [Page 4]


Internet Draft     draft-ietf-msec-secure-feedback-00


   RESERVED              0
   DE-REGISTER           1
   RESYNC                2
   NACKs                 3
   Future Use
   Private Use



   When REQ type is DE-REGISTER or RESYNC, there is no associated
   Request data. When REQ type is NACKs, Request data contains either a
   sequence of NACKs, or a range of NACKs, or a combination.

   Note: We may need a separate payload definition for the various types
   of Request data.

3.3 Integrity protection of FEEDBACK messages

   The AUTH payload is also new and defined as follows. The LKH ID is
   defined as in GDOI spec . The AUTH data is a MAC computed over the
   entire FEEDBACK message excluding the AUTH payload itself.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
     !           LKH ID              !            RESERVED2          !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
     ~                          AUTH data                            ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!




3.4 Processing at the members

   Members are aware of the Sequence number window maintained by the
   GCKS.  Thus a member can send FEEDBACK messages only before the GCKS
   has used a Sequence number within the Sequence window of the Sequence
   number it received. Members may not know the Sequence number being
   used by the GCKS. Therefore, a member must maintain a timer waiting
   for a response to the FEEDBACK message. If the member does not
   receive a response before the time expires, it may have to restart
   with the Registration protocol.




L. Dondeti, T. Hardjono                                       [Page 5]


Internet Draft     draft-ietf-msec-secure-feedback-00


3.5 Processing at the GCKS

   To process the FEEDBACK messages, the GCKS needs to allow them to
   have a Sequence number within a pre-defined window of the current
   Sequence number in the latest Rekey message from the GCKS.

4 Security Considerations

   The FEEDBACK message is encrypted, and authenticated. It provides
   replay protection within a window of the Sequence number in the Rekey
   messages. FEEDBACK messages are integrity protected using a MAC,
   which is not computationally intensive; thus, there is no threat of
   denial-of-service attacks using them. The number of FEEDBACK messages
   can be large, which is a potential problem (open to DoS attacks).

5 Bibliography

   [1] M. Baugher, R. Canetti, L. Dondeti, and F. Lindholm, "Group key
   management architecture," Internet Draft, Internet Engineering Task
   Force, Mar. 2003.  Work in progress.

   [2] D. Maughan, M. Schertler, M. Schneider, and J. Turner, "Internet
   security association and key management protocol (ISAKMP)," RFC
   2408(Proposed Standard), IETF, Nov. 1998.

   [3] M. Baugher, T. Hardjono, H. Harney, and B. Weis, "Group domain of
   interpretation for isakmp," Internet Draft, IETF, Dec. 2002.  Work in
   progress.

6 Authors' contact information


Lakshminath R. Dondeti
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821, USA
(978) 288-6406
ldondeti@nortelnetworks.com

Thomas Hardjono
Verisign Inc.
401 Edgewater Place, Suite 280
Wakefield, MA 01880, USA
thardjono@verisign.com







L. Dondeti, T. Hardjono                                       [Page 6]


Internet Draft     draft-ietf-msec-secure-feedback-00





















































L. Dondeti, T. Hardjono                                       [Page 7]