idnits 2.17.00 (12 Aug 2021) /tmp/idnits18531/draft-dondeti-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 (Feb 2003) is 7028 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 232 looks like a reference -- Missing reference section? '2' on line 236 looks like a reference -- Missing reference section? '3' on line 240 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-dondeti-ietf-msec-secure-feedback-00.txt Nortel Networks, Verisign 5 Expires: Aug 2003 Feb 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, and 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-dondeti-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-dondeti-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. In LKH, this 102 key corresponds to the leaf node a member is associated with. This 103 unique key is used to protect the integrity of the feedback message. 105 The Sequence number from the lost or the most recently received rekey 106 message can be used for replay protection. Such Sequence number use 107 for feedback messages, allows efficient implementation at the GCKS. 108 Specifically, the GCKS does not need to maintain per-member Sequence 109 numbers. 111 3.1 Rekey message 113 Our design of the feedback message is based on GDOI Rekey message 114 (although there is no reason to believe that this won't work for 115 GSAKMP rekey messages) or GROUPKEY-PUSH message: 117 Member GCKS 118 ------- ------ 119 <--- HDR*, SEQ, SA, KD, [CERT,] SIG 121 * protected by the Rekey SA KEK; Everything after the HDR is encrypted 123 The HDR is an ISAKMP header. The SEQ payload contains a monotonically 124 increasing sequence number. The SA payload can include one or more 125 SAKEK payloads and zero or more SATEK payloads. The KD payload con- 126 tains KEKs and TEKs corresponding to SAKEK and SATEK payloads. The 127 SIG payload signs the hash of a message formed by concatenating the 129 Internet Draft draft-dondeti-ietf-msec-secure-feedback-00 131 string "rekey" with the Rekey message (excluding SIG itself). The 132 message is encrypted (excluding the HDR) using the group KEK. 134 3.2 Feedback message 136 Member GCKS 137 ------- ------ 138 HDR*, SEQ, REQ, AUTH --> 140 * protected by the leaf/unique KEK of member; 141 Everything between the HDR and the AUTH payload is encrypted 143 The HDR is ISAKMP header payload (see RFC2408 [2]) and is formed sim- 144 ilar to that in GDOI (see Section 4.5 in [3]). The cookie pair is the 145 same as in the recently received Rekey message. The next payload is 146 the SEQ payload. The Exchange Type has a value for FEEDBACK-MESSAGE 147 (to be assigned a number). Length is computed as specified in 148 RFC2408. The rest of the fields are the same as in the received mes- 149 sage. 151 The SEQ payload contains the SEQ message in the most recently 152 received GROUPKEY-PUSH message. 154 The REQ payload is new (to be assigned a payload number) and contains 155 the Feedback message. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 160 ! Next Payload ! RESERVED ! Payload Length ! 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 162 ! REQ type ! RESERVED2 ! 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 164 ~ Request data ~ 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 167 REQ type value 168 -------- ----- 169 RESERVED 0 171 Internet Draft draft-dondeti-ietf-msec-secure-feedback-00 173 DE-REGISTER 1 174 RESYNC 2 175 NACKs 3 176 Future Use 177 Private Use 179 When REQ type is DE-REGISTER or RESYNC, there is no associated 180 Request data. When REQ type is NACKs, Request data contains either a 181 sequence of NACKs, or a range of NACKs, or a combination. 183 Note: We may need a separate payload definition for the various types 184 of Request data. 186 3.3 Integrity protection of FEEDBACK messages 188 The AUTH payload is also new and defined as follows. The LKH ID is 189 defined as in GDOI spec . The AUTH data is a MAC computed over the 190 entire FEEDBACK message excluding the AUTH payload itself. 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 195 ! Next Payload ! RESERVED ! Payload Length ! 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 197 ! LKH ID ! RESERVED2 ! 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 199 ~ AUTH data ~ 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 202 3.4 Processing at the members 204 Members are aware of the Sequence number window maintained by the 205 GCKS. Thus a member can send FEEDBACK messages only before the GCKS 206 has used a Sequence number within the Sequence window of the Sequence 207 number it received. Members may not know the Sequence number being 208 used by the GCKS. Therefore, a member must maintain a timer waiting 209 for a response to the FEEDBACK message. If the member does not 210 receive a response before the time expires, it may have to restart 211 with the Registration protocol. 213 Internet Draft draft-dondeti-ietf-msec-secure-feedback-00 215 3.5 Processing at the GCKS 217 To process the FEEDBACK messages, the GCKS needs to allow them to 218 have a Sequence number within a pre-defined window of the current 219 Sequence number in the latest Rekey message from the GCKS. 221 4 Security Considerations 223 The FEEDBACK message is encrypted, and authenticated. It provides 224 replay protection within a window of the Sequence number in the Rekey 225 messages. FEEDBACK messages are integrity protected using a MAC, 226 which is not computationally intensive; thus, there is no threat of 227 denial-of-service attacks using them. The number of FEEDBACK messages 228 can be large, which is a potential problem (open to DoS attacks). 230 5 Bibliography 232 [1] M. Baugher, R. Canetti, L. Dondeti, and F. Lindholm, "Group key 233 management architecture," Internet Draft, Internet Engineering Task 234 Force, Mar. 2003. Work in progress. 236 [2] D. Maughan, M. Schertler, M. Schneider, and J. Turner, "Internet 237 security association and key management protocol (ISAKMP)," RFC 238 2408(Proposed Standard), IETF, Nov. 1998. 240 [3] M. Baugher, T. Hardjono, H. Harney, and B. Weis, "Group domain of 241 interpretation for isakmp," Internet Draft, IETF, Dec. 2002. Work in 242 progress. 244 6 Authors' contact information 246 Lakshminath R. Dondeti 247 Nortel Networks 248 600 Technology Park Drive 249 Billerica, MA 01821, USA 250 (978) 288-6406 251 ldondeti@nortelnetworks.com 253 Thomas Hardjono 254 Verisign Inc. 255 401 Edgewater Place, Suite 280 256 Wakefield, MA 01880, USA 257 thardjono@verisign.com 258 Internet Draft draft-dondeti-ietf-msec-secure-feedback-00