One document matched: draft-ietf-msec-secure-feedback-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 21:58:37 |