idnits 2.17.1 draft-reddy-sfc-nsh-encrypt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 9, 2015) is 3305 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) == Unused Reference: 'RFC6043' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'RFC6407' is defined on line 479, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-07 ** Downref: Normative reference to an Informational draft: draft-ietf-sfc-architecture (ref. 'I-D.ietf-sfc-architecture') == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-00 ** Downref: Normative reference to an Informational draft: draft-ietf-sfc-problem-statement (ref. 'I-D.ietf-sfc-problem-statement') ** Downref: Normative reference to an Informational RFC: RFC 6043 == Outdated reference: A later version (-03) exists of draft-abiggs-saag-key-management-service-00 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC T. Reddy 3 Internet-Draft P. Patil 4 Intended status: Standards Track S. Fluhrer 5 Expires: October 11, 2015 P. Quinn 6 Cisco 7 April 9, 2015 9 Authenticated and encrypted NSH service chains 10 draft-reddy-sfc-nsh-encrypt-00 12 Abstract 14 This specification adds data origin authentication and optional 15 encryption directly to Network Service Headers (NSH) used for Service 16 Function Chaining. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 11, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 54 2.1. Definitions and Notation . . . . . . . . . . . . . . . . 3 55 3. Design considerations . . . . . . . . . . . . . . . . . . . . 3 56 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. NSH Format . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1. Ticket TLV . . . . . . . . . . . . . . . . . . . . . . . 7 59 5.2. Sequence Number TLV . . . . . . . . . . . . . . . . . . . 7 60 5.3. Authentication Tag TLV . . . . . . . . . . . . . . . . . 7 61 5.4. Encrypted Metadata . . . . . . . . . . . . . . . . . . . 8 62 6. Processing rules . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Encrypted NSH metadata Generation . . . . . . . . . . . . 8 64 6.2. Authenticated NSH data Generation . . . . . . . . . . . . 9 65 6.3. Sequence number validation for replay attack . . . . . . 9 66 6.4. NSH data Validation . . . . . . . . . . . . . . . . . . . 10 67 6.5. Decryption of NSH metadata . . . . . . . . . . . . . . . 10 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 10.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 Service function chaining (SFC) [I-D.ietf-sfc-architecture] involves 79 steering traffic flows through a set of service functions in a 80 specific order, such an ordered list of service functions is called a 81 Service Function Chain (SFC). The actual forwarding path used to 82 realize an SFC is called the Service Function Path (SFP). Network 83 Service Headers (NSH) [I-D.ietf-sfc-nsh] provides a mechanism to 84 carry metadata between service functions. The NSH structure is 85 defined in [I-D.ietf-sfc-nsh] and NSH data can be divided into two 86 parts: 88 o Path information used to construct the SFP. 90 o Metadata carrying the information about the packets being chained 92 NSH data is unauthenticated and unencrypted, forcing a service 93 topology that requires security to use a transport encapsulation that 94 support such features (e.g. IPsec). This draft adds authentication 95 and optional encryption directly to NSH. This way NSH data does not 96 have to rely on underlying transport encapsulation for security and 97 confidentiality. 99 This specification introduces new TLVs to carry fields necessary for 100 Authenticated and Encrypted NSH, and is hence only applicable to NSH 101 MD-Type 2 defined in [I-D.ietf-sfc-nsh]. 103 2. Notational Conventions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 This note uses the terminology defined in 110 [I-D.ietf-sfc-problem-statement]. 112 2.1. Definitions and Notation 114 KMS: Key Management Service. 116 Ticket: A Kerberos like object used to identify and deliver keys over 117 an untrusted network. 119 NSH imposer: Imposes NSH header including Service Path ID, Service 120 Index and metadata. 122 SF : Service function. 124 3. Design considerations 126 SFC [I-D.ietf-sfc-architecture] removes the constraint of strict 127 ordering of service functions and allows dynamic ordering of service 128 functions. Service function paths (SFP) could vary for different 129 traffic and it is not possible to pre-determine peer service 130 functions in service function paths and pre-distribute credentials 131 for security association between all possible combinations of peer 132 service functions for authentication and encryption of NSH data. 134 The keying material should be unique for each SFP so that only the 135 authorized service functions participating in the SFP can act on the 136 NSH data. A trusted KMS can be used to propagate keying material to 137 authorized service functions as and when needed and avoids the use of 138 pair-wise keys. A KMS based on symmetric keys has particular 139 advantages, as symmetric key algorithms are generally much less 140 computationally intensive than asymmetric key algorithms and the size 141 of cipher-text generated using symmetric key algorithm is smaller 142 compared to the cipher-text generated using asymmetric encryption 143 algorithm. Systems based on a KMS require a signaling mechanism that 144 allows peers to retrieve other peers dynamic credentials. A 145 convenient way to implement such a signaling scheme is to use a 146 ticket concept, similar to that in Kerberos [RFC4120] to identify and 147 deliver keys. The ticket can be forwarded in the NSH data. The NSH 148 imposer requests a ticket from the KMS and sends the ticket in NSH 149 data. The service function in SFP gets the ticket from NSH, requests 150 KMS to provide the keying material associated with the ticket. If 151 the service function is authorized then KMS returns the corresponding 152 keys. 154 Note: Key management services may introduce a single point of 155 (security) failure. The security requirements on the implementation 156 and protection of the KMS may therefore, in high-security 157 applications, be more or less equivalent to the requirements of an 158 AAA (Authentication, Authorization, and Accounting) server or a 159 Certification Authority (CA). 161 KMS is used in GDOI [[RFC6407]], MIKEY-TICKET [[RFC6043]], end-to-end 162 encryption key management service 163 [I-D.abiggs-saag-key-management-service] etc. 165 4. Overview 167 The service functions do not share any credentials; instead, they 168 trust a third party, the KMS, with which they have or can establish 169 shared credentials. These pre-established trust relations are used 170 to establish a security association between service functions. 172 The NSH imposer requests keys and a ticket from the KMS. The request 173 message also includes identities of the service functions authorized 174 to receive the keying material associated with the ticket. Each SF 175 is referenced using an identifier that is unique within an SF-enabled 176 domain. If the request is authorized then KMS generates the 177 encryption and message integrity keys (referred to as ENC and MAC 178 keys), ticket, and returns them in a response message. The ticket 179 could be self-contained (key encrypted in the ticket) or just a 180 handle to some internal datastructure within the KMS. The need to 181 encrypt NSH metadata is determined based on the classification 182 decision and the metadata conveyed in NSH. The encryption and 183 authentication algorithms will either be negotiated between the NSH 184 imposer and KMS or determined by the KMS and conveyed to the NSH 185 imposer. 187 The NSH imposer includes the ticket in NSH data. The NSH data is 188 protected using the MAC key and optionally NSH metadata is encrypted 189 using the ENC key. Service functions in the SFP forward the ticket 190 to the KMS and request the KMS to provide the keying material. If 191 the service function is authorized and the ticket is valid then the 192 KMS retrieves the keys and algorithms associated with the ticket and 193 conveys them to the service function. The other alternative 194 technique is that KMS implicitly pushes the keying material to 195 service functions authorized by the NSH imposer. 197 If the SFP for a flow changes then NSH imposer requests new keys and 198 a new ticket from KMS. The request message from NSH imposer to KMS 199 includes identities of the service functions authorized to receive 200 the keying material associated with the new ticket. For subsequent 201 packets of the flow the new ticket will be conveyed in the NSH data, 202 NSH data will be integrity protected using the new MAC key and NSH 203 metadata encrypted using the new ENC key. 205 Figure 1 shows an example of NSH imposer requesting keys and ticket 206 from the KMS. The request message includes identifiers of SF1 and 207 SF2 service functions authorized to receive keying material 208 associated with the ticket. KMS returns the ENC key, MAC key and 209 ticket in the response message. The NSH imposer includes the ticket 210 in the NSH data. SF1 in the SFP forwards the ticket to the KMS and 211 requests the KMS for keying material associated with the ticket (In 212 Ticket resolve request message). If SF1 is authorized and the ticket 213 is valid then KMS retrieves the keys and algorithms associated with 214 the ticket and conveys them to the SF1 (In Resolve response message). 215 Similarly, SF2 retrieves the keying material associated with the 216 ticket from KMS. 218 +----------------+ +-------+ +------+ +------+ 219 | NSH Imposer | | KMS | | SF1 | | SF2 | 220 +----+-----------+ +----+--+ +----+-+ +--+---+ 221 | | | | 222 | | | | 223 | Ticket Request | | | 224 +---------------------------------->| | | 225 | | | | 226 | Ticket Response | | | 227 |<----------------------------------+ | | 228 | | | | 229 | Ticket sent in NSH | | | 230 +--------------------------------------------------->+----------->| 231 | | | | 232 | | Ticket resolve | | 233 | |<------------+--+ | 234 | | + | 235 | | Resolve response | 236 | +------+-------->+ | 237 | | | | 238 | | Ticket resolve | | 239 | |<-----+------+---------------+ 240 | | Resolve response | 241 | +-------+-------------------->| 242 + + + + 244 Figure 1: Interaction with KMS 246 5. NSH Format 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Base Header | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Service Path Header | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Ticket | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Sequence Number | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Encrypted Metadata | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Authentication Tag | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 5.1. Ticket TLV 265 A variable length Kerberos-like object used to identify and deliver 266 keys over an untrusted network to service functions. This is a 267 mandatory TLV that MUST be present if an authenticated and encrypted 268 NSH solution is desired. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | TLV Class | TKT |R|R|R| Len | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | TICKET | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 5.2. Sequence Number TLV 280 A 32-bit sequence number per ticket. In this solution, a sequence 281 number needs to be incremented every time NSH is included by the NSH 282 imposer. The number should not be incremented if an existing NSH is 283 being updated. This is a mandatory TLV that MUST be present if an 284 authenticated and encrypted NSH solution is desired. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | TLV Class | SEQ |R|R|R| 1 | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Sequence Number | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 5.3. Authentication Tag TLV 296 A variable-length TLV that carries the hash based Message 297 Authentication Codes for the entire NSH calculated using the MAC key. 298 If Authenticated Encryption with Associated Data (AEAD) algorithm 299 defined in [RFC5116] is used then there is no need explicitly compute 300 HMAC and include this TLV. 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | TLV Class | AUTH-TAG |R|R|R| Len | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Authentication Tag | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 5.4. Encrypted Metadata 312 A variable-length TLV that carries the metadata encrypted using ENC 313 key obtained from the KMS. The C bit in the Type field MUST be set 314 to 1 indicating that the TLV is mandatory for the receiver to 315 understand and process. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | TLV Class | ENC-MD |R|R|R| Len | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | IV Len | Initialization Vector | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Encrypted Metadata | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Randomly generated Initialization Vector (IV) prevents generation of 328 identical cipher-text from packets which have identical metadata, use 329 of IV in AES CBC is explained in [RFC3602]. 331 If AEAD algorithm is used 333 o The Initialization Vector field will carry the nonce and the 334 length of the nonce for AEAD algorithms is specified in [RFC5116]. 336 o The associated data MUST be the entire NSH data excluding the 337 metadata to be encrypted and the nonce value. 339 If one or more service functions in the SFP are authorized to 340 validate the message integrity of NSH data and update the unencrypted 341 NSH data but not decrypt the encrypted metadata then AEAD algorithm 342 MUST NOT be used and these service functions MUST only be given 343 access to the MAC key. 345 6. Processing rules 347 The following sections describe processing rules for authenticated 348 and encrypted NSH. 350 6.1. Encrypted NSH metadata Generation 352 An NSH imposer can encrypt all NSH metadata or only a subset of 353 metadata i.e., encrypted and unencrypted metadata may be carried 354 simultaneously. Using the ENC key and encryption algorithm obtained 355 from the KMS, the imposer encrypts metadata of choice and inserts the 356 resulting payload in the encrypted metadata TLV. 358 An authorized entity in the service path that intends to update 359 encrypted metadata, MUST also do the above. 361 If NSH encryption is desired, encryption is performed first, before 362 the integrity algorithm is applied. This order of processing 363 facilitates rapid detection and rejection of bogus packets by the 364 receiver, prior to decrypting the metadata, hence potentially 365 reducing the impact of denial of service (DoS) attacks. 367 6.2. Authenticated NSH data Generation 369 An NSH imposer inserts an Authentication Tag TLV for data origin 370 authentication and integrity protection. After requesting ENC and 371 MAC keys from the KMS, the imposer computes the message integrity for 372 the entire NSH data using the MAC key and HMAC algorithm. It inserts 373 the result in the AUTH-TAG TLV. The length of the Authentication 374 Data field is decided by the HMAC algorithm adopted for the 375 particular ticket. 377 An entity in the service function path that intends to update NSH 378 MUST do the above to maintain message integrity of the NSH for 379 subsequent validations. 381 6.3. Sequence number validation for replay attack 383 A Sequence Number is an unsigned 32-bit counter value that increases 384 by one for each NSH created and sent from the NSH imposer, i.e., a 385 per-ticket packet sequence number. The field is mandatory and MUST 386 always be present. Processing of the Sequence Number field is at the 387 discretion of the receiver, but all implementations MUST be capable 388 of validating that the Sequence Number that does not duplicate the 389 Sequence Number of any other NSH received during the life of the 390 ticket. 392 The NSH imposer's counter is initialized to 0 when a new ticket is to 393 be used . The sender increments the Sequence Number counter for this 394 ticket and inserts the 32-bit value into the Sequence Number TLV. 395 Thus the first NSH sent using a given ticket will contain a Sequence 396 Number of 1. The imposer checks to ensure that the counter has not 397 cycled before inserting the new value in the Sequence Number TLV. In 398 other words, the sender MUST NOT send a packet on a ticket if doing 399 so would cause the Sequence Number to rollover. Sequence Number 400 counters of all participating nodes MUST be reset by establishing a 401 new ticket prior to the transmission of the 2^32nd packet of NSH for 402 a particular ticket. 404 6.4. NSH data Validation 406 When an SFC node receives an NSH header with encrypted metadata, it 407 MUST first ensure that all mandatory TLVs required for NSH data 408 authentication exist. The node MUST discard NSH if mandatory TLVs 409 are absent or if the sequence number is invalid (described in 410 Section 6.3). The node should then go on to do data validation. The 411 node calculates the message integrity for the entire NSH data using 412 the MAC key and HMAC algorithm obtained from the KMS for the ticket 413 being carried in NSH. If the value of the newly generated digest is 414 identical to the one in NSH, the node is certain that the header has 415 not been tampered and validation succeeds. Otherwise, the NSH MUST 416 be discarded. 418 6.5. Decryption of NSH metadata 420 After NSH data validation is complete, an SFC node decrypts metadata 421 using the ENC key and decryption algorithm obtained from the KMS for 422 the ticket in NSH. If AEAD algorithm is used then it has only a 423 single output, either a plaintext or a special symbol FAIL that 424 indicates that the inputs are not authentic. 426 7. IANA Considerations 428 TODO 430 8. Security Considerations 432 The interaction between the Service functions and the KMS requires 433 Transport Layer Security (TLS) with a ciphersuite offering 434 confidentiality protection. The ENC and MAC keys MUST NOT be 435 transmitted in clear since this would completely destroy the security 436 benefits of the proposed scheme. 438 9. Acknowledgements 440 Authors would like to thank Dan Wing and Jim Guichard for their 441 comments and review. 443 10. References 445 10.1. Normative References 447 [I-D.ietf-sfc-architecture] 448 Halpern, J. and C. Pignataro, "Service Function Chaining 449 (SFC) Architecture", draft-ietf-sfc-architecture-07 (work 450 in progress), March 2015. 452 [I-D.ietf-sfc-nsh] 453 Quinn, P. and U. Elzur, "Network Service Header", draft- 454 ietf-sfc-nsh-00 (work in progress), March 2015. 456 [I-D.ietf-sfc-problem-statement] 457 Quinn, P. and T. Nadeau, "Service Function Chaining 458 Problem Statement", draft-ietf-sfc-problem-statement-13 459 (work in progress), February 2015. 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 465 Algorithm and Its Use with IPsec", RFC 3602, September 466 2003. 468 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 469 Kerberos Network Authentication Service (V5)", RFC 4120, 470 July 2005. 472 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 473 Encryption", RFC 5116, January 2008. 475 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 476 Modes of Key Distribution in Multimedia Internet KEYing 477 (MIKEY)", RFC 6043, March 2011. 479 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 480 of Interpretation", RFC 6407, October 2011. 482 10.2. Informative References 484 [I-D.abiggs-saag-key-management-service] 485 Biggs, A. and S. Cooley, "Key Management Service 486 Architecture", draft-abiggs-saag-key-management-service-00 487 (work in progress), November 2014. 489 Authors' Addresses 491 Tirumaleswar Reddy 492 Cisco Systems, Inc. 494 Email: tireddy@cisco.com 495 Prashanth Patil 496 Cisco Systems, Inc. 498 Email: praspati@cisco.com 500 Scott Fluhrer 501 Cisco Systems, Inc. 503 Email: sfluhrer@cisco.com 505 Paul Quinn 506 Cisco Systems, Inc. 508 Email: paulq@cisco.com