idnits 2.17.1 draft-ietf-msec-secure-feedback-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jun 2003) is 7618 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 233 looks like a reference -- Missing reference section? '2' on line 237 looks like a reference -- Missing reference section? '3' on line 241 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft L. Dondeti, T. Hardjono 4 draft-ietf-msec-secure-feedback-00.txt Nortel Networks, Verisign 5 Expires: Dec 2003 Jun 2003 7 Securing Feedback Messages: Secure and Scalable Many-to-one Communication 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference mate- 22 rial or to cite them other than as "work in progress". 24 To view the list Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 Abstract 29 Members in a secure group may need to communicate to the GCKS to 30 Deregister from the group, for SA resynchronization, or to request 31 retransmission of a Rekey message. A simple solution is to keep the 32 registration SA around, but that comes at the expense of O(n) SA 33 maintenance, and storage at the GCKS. Each member is also responsible 34 for maintaining an extra SA. We propose an efficient method for mem- 35 bers to securely send messages to the GCKS, using the Rekey SA. 37 Internet Draft draft-ietf-msec-secure-feedback-00 39 Table of Contents 41 1. Introduction to GSA 43 2. Need for Many-to-one Secure communication in Secure Groups 45 3. Proposed Solution 47 3.1. Rekey Message 49 3.2. Feedback Message 51 3.3. Integrity Protection of Feedback Message 53 3.4. Processing at the members 55 3.5. Processing at the GCKS 57 4. Security Considerations 59 5. References 61 6. Authors' Contact Information 63 1 Introduction to GSA 65 The GKM architecture [1] proposed by MSEC defines three SAs: Regis- 66 tration SA, Rekey SA and Data Security SA. These three SAs comprise 67 the Group SA (GSA). The Registration SA protects member initializa- 68 tion process, and protects the downloading of Rekey and the Data 69 Security SAs. At this point the GCKS uses a one-to-one secure chan- 70 nel, protected by the Registration SA, for secure communication. 72 The Rekey SA protects Rekey messages, which contain updates to the 73 Rekey SA or a new Data Security SA. The Data Security SA protects 74 data transmissions to the group. 76 For scalable operation, it is inefficient to keep the registration 77 SAs alive, especially in large groups. Each registration SA may have 78 to be stored and maintained (rekeyed periodically) from the time the 79 corresponding member joins the group until it leaves. This is 81 Internet Draft draft-ietf-msec-secure-feedback-00 83 expensive due to the large state storage required and the computation 84 and communication overhead due to SA maintenance. 86 2 Need for many-to-one communication in secure groups 88 Secure communication in groups as defined in GKM architecture [1] is 89 mostly one-way from the GCKS to the members (sender and receivers), 90 and from the sender to the receivers. As noted earlier, the Rekey and 91 the Data Security SAs are used to protect these communications. 93 But, from time to time members may need to contact the GCKS, for 94 example, to request retransmission of a rekey message, for GSA syn- 95 chronization, or to Deregister from the group. 97 3 Proposed solution 99 We propose a scalable protocol to send feedback securely using the 100 Rekey SA. Note that in most, if not all, group key management algo- 101 rithms, the GCKS shares a unique key with each member. For example, 102 in LKH, this key corresponds to the leaf node a member is associated 103 with. We propose to use the unique key to protect the integrity of 104 the feedback message. 106 The Sequence number from the lost or the most recently received rekey 107 message can be used for replay protection. Such Sequence number use 108 for feedback messages, allows efficient implementation at the GCKS. 109 Specifically, the GCKS does not need to maintain per-member Sequence 110 numbers. 112 3.1 Rekey message 114 Our design of the feedback message is based on GDOI Rekey message 115 (although there is no reason to believe that this won't work for 116 GSAKMP rekey messages) or GROUPKEY-PUSH message: 118 Member GCKS 119 ------- ------ 120 <--- HDR*, SEQ, SA, KD, [CERT,] SIG 122 * protected by the Rekey SA KEK; Everything after the HDR is encrypted 124 The HDR is an ISAKMP header. The SEQ payload contains a monotonically 125 increasing sequence number. The SA payload can include one or more 126 SAKEK payloads and zero or more SATEK payloads. The KD payload con- 127 tains KEKs and TEKs corresponding to SAKEK and SATEK payloads. The 129 Internet Draft draft-ietf-msec-secure-feedback-00 131 SIG payload signs the hash of a message formed by concatenating the 132 string "rekey" with the Rekey message (excluding SIG itself). The 133 message is encrypted (excluding the HDR) using the group KEK. 135 3.2 Feedback message 137 Member GCKS 138 ------- ------ 139 HDR*, SEQ, REQ, AUTH --> 141 * protected by the leaf/unique KEK of member; 142 Everything between the HDR and the AUTH payload is encrypted 144 The HDR is ISAKMP header payload (see RFC2408 [2]) and is formed sim- 145 ilar to that in GDOI (see Section 4.5 in [3]). The cookie pair is the 146 same as in the recently received Rekey message. The next payload is 147 the SEQ payload. The Exchange Type has a value for FEEDBACK-MESSAGE 148 (to be assigned a number). Length is computed as specified in 149 RFC2408. The rest of the fields are the same as in the received mes- 150 sage. 152 The SEQ payload contains the SEQ message in the most recently 153 received GROUPKEY-PUSH message. 155 The REQ payload is new (to be assigned a payload number) and contains 156 the Feedback message. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 161 ! Next Payload ! RESERVED ! Payload Length ! 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 163 ! REQ type ! RESERVED2 ! 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 165 ~ Request data ~ 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 168 REQ type value 169 -------- ----- 171 Internet Draft draft-ietf-msec-secure-feedback-00 173 RESERVED 0 174 DE-REGISTER 1 175 RESYNC 2 176 NACKs 3 177 Future Use 178 Private Use 180 When REQ type is DE-REGISTER or RESYNC, there is no associated 181 Request data. When REQ type is NACKs, Request data contains either a 182 sequence of NACKs, or a range of NACKs, or a combination. 184 Note: We may need a separate payload definition for the various types 185 of Request data. 187 3.3 Integrity protection of FEEDBACK messages 189 The AUTH payload is also new and defined as follows. The LKH ID is 190 defined as in GDOI spec . The AUTH data is a MAC computed over the 191 entire FEEDBACK message excluding the AUTH payload itself. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 196 ! Next Payload ! RESERVED ! Payload Length ! 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 198 ! LKH ID ! RESERVED2 ! 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 200 ~ AUTH data ~ 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 203 3.4 Processing at the members 205 Members are aware of the Sequence number window maintained by the 206 GCKS. Thus a member can send FEEDBACK messages only before the GCKS 207 has used a Sequence number within the Sequence window of the Sequence 208 number it received. Members may not know the Sequence number being 209 used by the GCKS. Therefore, a member must maintain a timer waiting 210 for a response to the FEEDBACK message. If the member does not 211 receive a response before the time expires, it may have to restart 212 with the Registration protocol. 214 Internet Draft draft-ietf-msec-secure-feedback-00 216 3.5 Processing at the GCKS 218 To process the FEEDBACK messages, the GCKS needs to allow them to 219 have a Sequence number within a pre-defined window of the current 220 Sequence number in the latest Rekey message from the GCKS. 222 4 Security Considerations 224 The FEEDBACK message is encrypted, and authenticated. It provides 225 replay protection within a window of the Sequence number in the Rekey 226 messages. FEEDBACK messages are integrity protected using a MAC, 227 which is not computationally intensive; thus, there is no threat of 228 denial-of-service attacks using them. The number of FEEDBACK messages 229 can be large, which is a potential problem (open to DoS attacks). 231 5 Bibliography 233 [1] M. Baugher, R. Canetti, L. Dondeti, and F. Lindholm, "Group key 234 management architecture," Internet Draft, Internet Engineering Task 235 Force, Mar. 2003. Work in progress. 237 [2] D. Maughan, M. Schertler, M. Schneider, and J. Turner, "Internet 238 security association and key management protocol (ISAKMP)," RFC 239 2408(Proposed Standard), IETF, Nov. 1998. 241 [3] M. Baugher, T. Hardjono, H. Harney, and B. Weis, "Group domain of 242 interpretation for isakmp," Internet Draft, IETF, Dec. 2002. Work in 243 progress. 245 6 Authors' contact information 247 Lakshminath R. Dondeti 248 Nortel Networks 249 600 Technology Park Drive 250 Billerica, MA 01821, USA 251 (978) 288-6406 252 ldondeti@nortelnetworks.com 254 Thomas Hardjono 255 Verisign Inc. 256 401 Edgewater Place, Suite 280 257 Wakefield, MA 01880, USA 258 thardjono@verisign.com 259 Internet Draft draft-ietf-msec-secure-feedback-00