idnits 2.17.00 (12 Aug 2021) /tmp/idnits56004/draft-melnikov-itot-tls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 293. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2126, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2126, updated by this document, for RFC5378 checks: 1995-11-03) -- 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 (January 2006) is 5963 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) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- No information found for draft-melnikov-nsap-ipv6-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NSAP-IPV6' -- No information found for draft-melnikov-rfc1278bis-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFC1278bis' Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: TLS support in ITOT D. Wilson 3 Document: draft-melnikov-itot-tls-01.txt S. Kille 4 Expires: July 2006 A. Melnikov 5 Intended category: Standard Track Isode Ltd. 6 Updates: RFC 2126 January 2006 8 TLS support in ITOT 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 A revised version of this draft document will be submitted to the RFC 34 editor as a Proposed Standard for the Internet Community. Discussion 35 and suggestions for improvement are requested, and should be sent 36 directly to the authors. Distribution of this draft is unlimited. 38 Abstract 40 This document describes an extension to the ITOT (ISO Transport 41 Service on top of TCP) class 2 service that allows an ITOT Initiator 42 and Responder to use TLS (Transport Layer Security) to provide 43 private, authenticated communication over the Internet. This gives 44 ITOT agents the ability to protect some or all of their 45 communications from eavesdroppers and attackers. 47 1. Conventions Used in this Document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 52 Editorial comments/questions or missing paragraphs are marked in the 53 text with << and >>. 55 2. Negotiation of TLS in ITOT 57 This document extends Connection Establishment procedures defined in 58 the Section 4.2.1 of [ITOT]. 60 This document redefines bit 2 in the Additional Option parameter (RFC 61 2126, Section 6.6), to be used for negotiating TLS. The bit #2 was 62 chosen as this bit is not currently meaningful for the class 2. 64 Connection Request and Connection Confirmation TPDUs may negotiate 65 use of TLS service. TLS service is selected by setting bit 2 of the 66 "Additional Option" parameter, and is negotiated using the mechanism 67 specified in ISO 8073. 69 The default is not to use the "TLS Service". 71 The Initiator requests to commencement of a TLS negotiation by 72 setting the bit 2 in the Additional Option parameter. If the 73 Responder replies with Connection Confirmation TPDU that also has 74 this bit set, this means that the Initiator is able and willing to 75 negotiate TLS. 77 <> 82 <> 85 A [TLS] negotiation begins immediately after the end of TPKT Packet 86 containing the Connection Confirmation with the Additional Option 87 parameter bit # 2 set. 89 Note, that at this point the Initiator MUST NOT send further TPKT 90 Packets until TLS negotiation completes (successfully or not). 91 Similarly, the Responder MUST generate and send replies to all 92 requests received before the TPKT TLS Packet, before proceeding with 93 TLS negotiation. 95 <> 98 If the Responder receives a Connection Request packet containing TLS 99 negotiation request and TLS is already active, it MUST refuse the 100 request by not setting the bit # 2 in the corresponding Connection 101 Confirmation response. 103 Note, that once TLS negotiation is successful, all further packets 104 will be protected by TLS, even for connections established prior to 105 TLS negotiation. <> 108 Note, that the Connect Request may contain Connect Data. Such data 109 will be tranferred in the clear. If the Initiator is willing to 110 protect the data, it must not use the Connect Data in the Connect 111 Request. 113 <> 115 2.1. New NSAPA types for ITOT over TLS 117 This document extends the definition of "NSAPA for IPv6 address and 118 port", Section 2 of [NSAP-IPV6]. 120 The IDI value 1 is hereby reserved for ITOT over TLS, when the 121 Initiator would like to perform TLS negotiation, but it is not 122 required. 124 The IDI value 2 is reserved for ITOT over TLS, when successful TLS 125 negotiation is mandatory. <> 128 This document also extends IPv4 NSAPAs: two new prefixes are 129 allocated under the Telex number 00728722 (see also [RFC1277], 130 section 4.5). The prefix 13 is hereby reserved for ITOT over TLS, 131 when the Initiator would like to perform TLS negotiation, but it is 132 not required. The prefix 23 is reserved for ITOT over TLS, when 133 successful TLS negotiation is mandatory. 135 2.1. Macro for ITOT over TLS NSAPA types 137 This section adds a couple of macro to the list defined in 138 [RFC1278bis]. 140 +-------------------+----------------------------+ 141 | Macro | Value | 142 +-------------------+----------------------------+ 143 | ITOT-TLSOPT-IPv6 |IPV6FULL+1+RFC-1006++ | 144 | ITOT-TLSREQ-IPv6 |IPV6FULL+2+RFC-1006++ | 145 +-------------------+----------------------------+ 147 3. Security Considerations 149 Initiators and Responders that implement the TLS extension to ITOT as 150 defined in this document MUST implement the TLS_RSA_WITH_RC4_128_MD5 151 [TLS] cipher suite, and SHOULD implement the 152 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is 153 important as it assures that any two compliant implementations can be 154 configured to interoperate. All other cipher suites are OPTIONAL. 156 During the [TLS] negotiation, the Initiator MUST check its 157 understanding of the Responder's hostname against the Responder's 158 identity as presented in the server Certificate message, in order to 159 prevent man-in-the-middle attacks. If the match fails, the Initiator 160 SHOULD either ask for explicit user confirmation, or terminate the 161 connection and indicate that the Responder's identity is suspect. 162 Matching is performed according to these rules: 164 The Initiator MUST use the Responder's hostname it used to open 165 the connection as the value to compare against the Responder 166 name as expressed in the Responder (server) certificate. The 167 Initiator MUST NOT use any form of the Responder hostname 168 derived from an insecure remote source (e.g., insecure DNS 169 lookup). CNAME canonicalization is not done. 171 If a subjectAltName extension of type dNSName is present in the 172 certificate, it SHOULD be used as the source of the Responder's 173 identity. 175 Matching is case-insensitive. 177 A "*" wildcard character MAY be used as the left-most name 178 component in the certificate. For example, *.example.com would 179 match a.example.com, foo.example.com, etc. but would not match 180 example.com. 182 If the certificate contains multiple names (e.g., more than one 183 dNSName field), then a match with any one of the fields is 184 considered acceptable. 186 Both the Initiator and Responder MUST check the result of the 187 TLS request and subsequent [TLS] negotiation to see whether 188 acceptable authentication or privacy was achieved. 190 4. IANA Considerations 192 IANA is requested to add the following IDIs below the AFI <> in the registry of the OSI NSAPAs: 194 : 196 IDI Value Description Format Definition 197 ---------- ----------------------- ---------------------------- 198 '1' ITOT over TLS over IPv6 , section 2.1 199 (optional TLS) 200 ---------- ----------------------- ---------------------------- 201 '2' ITOT over TLS over IPv6 , section 2.1 202 (mandatory TLS) 204 5. Acknowledgments 206 This document borrows some text from RFC 2126 and RFC 3501. 208 6. References 210 6.1. Normative references 212 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", RFC 2119, March 1997. 215 [ITOT] Pouffary, Y. and A. Young, "ISO Transport Service on top of 216 TCP (ITOT)", RFC 2126, March 1997. 218 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 219 2246, January 1999. 221 [RFC1277] Kille, S., "Encoding Network Addresses to support operation 222 over non-OSI lower layers", RFC 1277, November 1991. 224 [NSAP-IPV6] Wilson, D., Kille, S. and A. Melnikov, "Network Address 225 to support OSI over IPv6", work in progress, draft-melnikov-nsap- 226 ipv6-XX.txt. 228 [RFC1278bis] Kille, S. and A. Melnikov, "A string encoding of 229 Presentation Address", work in progress, draft-melnikov-rfc1278bis- 230 XX.txt. 232 6.2. Informative references 234 <<[ISO8348] ISO. "International Standard 8348. Information 235 Processing Systems - Open Systems Interconnection: Network Service 236 Definition." [ITU Recommendation X.213]>> 238 7. Author's Addresses 240 David Wilson 241 Steve Kille 242 Alexey Melnikov 244 Isode Ltd. 245 5 Castle Business Village, 246 36 Station Road, 247 Hampton, Middlesex, 248 TW12 2BX, United Kingdom 250 8. Full Copyright Statement 252 Copyright (C) The Internet Society (2006). 254 This document is subject to the rights, licenses and restrictions 255 contained in BCP 78, and except as set forth therein, the authors 256 retain all their rights. 258 This document and the information contained herein are provided on an 259 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 260 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 261 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 262 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 263 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 264 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 266 Acknowledgement 268 Funding for the RFC Editor function is currently provided by the 269 Internet Society. 271 9. Intellectual Property 273 The IETF takes no position regarding the validity or scope of any 274 Intellectual Property Rights or other rights that might be claimed to 275 pertain to the implementation or use of the technology described in 276 this document or the extent to which any license under such rights 277 might or might not be available; nor does it represent that it has 278 made any independent effort to identify any such rights. Information 279 on the procedures with respect to rights in RFC documents can be 280 found in BCP 78 and BCP 79. 282 Copies of IPR disclosures made to the IETF Secretariat and any 283 assurances of licenses to be made available, or the result of an 284 attempt made to obtain a general license or permission for the use of 285 such proprietary rights by implementers or users of this 286 specification can be obtained from the IETF on-line IPR repository at 287 http://www.ietf.org/ipr. 289 The IETF invites any interested party to bring to its attention any 290 copyrights, patents or patent applications, or other proprietary 291 rights that may cover technology that may be required to implement 292 this standard. Please address the information to the IETF at ietf- 293 ipr@ietf.org.