idnits 2.17.1 draft-zorn-dime-n2n-sec-lite-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 4, 2012) is 4314 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: 'RFC3748' is defined on line 149, but no explicit reference was found in the text == Unused Reference: 'RFC4072' is defined on line 153, but no explicit reference was found in the text == Unused Reference: 'RFC4398' is defined on line 157, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 160, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-smime-cms-rsa-kem' is defined on line 166, but no explicit reference was found in the text == Unused Reference: 'RFC5216' is defined on line 172, but no explicit reference was found in the text == Unused Reference: 'RFC5247' is defined on line 175, but no explicit reference was found in the text == Unused Reference: 'RFC5295' is defined on line 179, but no explicit reference was found in the text == Unused Reference: 'RFC5296' is defined on line 184, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5296 (Obsoleted by RFC 6696) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Network Zen 4 Intended status: Standards Track Q. Wu 5 Expires: January 5, 2013 Huawei 6 July 4, 2012 8 A Lightweight Approach to Node-to-Node Security in Diameter 9 draft-zorn-dime-n2n-sec-lite-03 11 Abstract 13 This document describes a lightweight method for cryptographically 14 protecting a portion of the contents of a Diameter message in transit 15 between an arbitrary pair of Diameter nodes. The scheme assumes that 16 the destination node possesses an X.509 certificate containing an RSA 17 public key and that that certificate is retrievable through a DNS 18 query by the node originating the message. 20 In addition to describing the operation of the protocol, this note 21 specifies an Attribute-Value Pair (AVP) for the encapsulation of 22 encrypted AVPs. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. This document may not be modified, 28 and derivative works of it may not be created, and it may not be 29 published except as an Internet-Draft. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 5, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Client Operation . . . . . . . . . . . . . . . . . . . . . 3 64 3.1.1. Key Establishment . . . . . . . . . . . . . . . . . . . 3 65 3.1.2. Protected Data Transfer . . . . . . . . . . . . . . . . 3 66 3.2. Server Operation . . . . . . . . . . . . . . . . . . . . . 3 67 3.2.1. Key Establishment . . . . . . . . . . . . . . . . . . . 3 68 3.2.2. Protected Data Transfer . . . . . . . . . . . . . . . . 4 69 4. Attribute-Value Pair Definitions . . . . . . . . . . . . . . . 4 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 4 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1. Introduction 79 Historically, Authentication, Authorization and Accounting (AAA) 80 network traffic has been secured on a hop-by-hop basis: messages 81 between AAA entities (such as Diameter clients, agents and servers) 82 have been protected on the wire but those entities have had 83 unfettered access to the message contents. This has not typically 84 been considered to be a concern when all of the entities in question 85 were within the same sphere of administrative control, but may be 86 problematic if the messages pass through an outside system (for 87 example, an agent residing in an intermediate domain in a roaming 88 situation). This document describes a lightweight method for 89 cryptographically protecting a portion of the contents of a Diameter 90 message while in transit between an arbitrary pair of Diameter nodes. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 3. Protocol Operation 100 The following sections describe the operation of the proposed end-to- 101 end security scheme. Although key establishment and data transfer 102 are discussed separately, both will usually take place in the same 103 message. 105 3.1. Client Operation 107 3.1.1. Key Establishment 109 TBC. 111 3.1.2. Protected Data Transfer 113 TBC. 115 3.2. Server Operation 117 3.2.1. Key Establishment 119 TBC. 121 3.2.2. Protected Data Transfer 123 TBC. 125 4. Attribute-Value Pair Definitions 127 This section defines a container AVP for the transport of encrypted 128 AVPs in Diameter applications. 130 5. Security Considerations 132 The security considerations applicable to the Diameter Base Protocol 133 [RFC3588] are also applicable to this document. 135 6. IANA Considerations 137 TBC. 139 7. References 141 7.1. Normative References 143 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 144 Requirement Levels", BCP 14, RFC 2119, March 1997. 146 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 147 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 149 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 150 Levkowetz, "Extensible Authentication Protocol (EAP)", 151 RFC 3748, June 2004. 153 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 154 Authentication Protocol (EAP) Application", RFC 4072, 155 August 2005. 157 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 158 System (DNS)", RFC 4398, March 2006. 160 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 161 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 162 May 2008. 164 7.2. Informative References 166 [I-D.ietf-smime-cms-rsa-kem] 167 Brainard, J., Turner, S., Randall, J., and B. Kaliski, 168 "Use of the RSA-KEM Key Transport Algorithm in CMS", 169 draft-ietf-smime-cms-rsa-kem-13 (work in progress), 170 May 2010. 172 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 173 Authentication Protocol", RFC 5216, March 2008. 175 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 176 Authentication Protocol (EAP) Key Management Framework", 177 RFC 5247, August 2008. 179 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 180 "Specification for the Derivation of Root Keys from an 181 Extended Master Session Key (EMSK)", RFC 5295, 182 August 2008. 184 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 185 authentication Protocol (ERP)", RFC 5296, August 2008. 187 Authors' Addresses 189 Glen Zorn 190 Network Zen 191 227/358 Thanon Sanphawut 192 Bang Na, Bangkok 10260 193 Thailand 195 Phone: +66 (0) 87-040-4617 196 Email: glenzorn@gmail.com 198 Qin Wu 199 Huawei Technologies Co., Ltd. 200 101 Software Avenue, Yuhua District 201 Nanjing, Jiangsu 21001 202 China 204 Phone: +86-25-84565892 205 Email: sunseawq@huawei.com