idnits 2.17.1 draft-ietf-nfsv4-channel-bindings-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 14) being 61 lines 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.) ** There are 44 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 2003) is 7499 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: 'RFC3530' is mentioned on line 282, but not defined ** Obsolete undefined reference: RFC 3530 (Obsoleted by RFC 7530) == Unused Reference: 'TELNET' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'DNS' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'DNSSEC' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'RFC2203' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'RFC2623' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'NFSv4' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'SPNEGO' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'CCM' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC2744' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'TCP' is defined on line 621, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3008 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3530 (ref. 'NFSv4') (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 2478 (ref. 'SPNEGO') (Obsoleted by RFC 4178) ** Obsolete normative reference: RFC 1602 (ref. 'RFC2026') (Obsoleted by RFC 2026) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) Summary: 6 errors (**), 0 flaws (~~), 15 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Nicolas Williams 3 INTERNET-DRAFT Sun Microsystems 4 October 2003 6 On the Use of Channel Bindings to Secure Channels 7 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 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 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This draft expires on March 1st, 2004. Please send comments to the 32 author. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document defines and formalizes the concept of channel bindings 41 to secure layers and defines the actual contents of channel bindings 42 for several secure channels. 44 The concept of channel bindings allows applications to prove that the 45 end-points of two secure channels are the same by binding 46 authentication at one network layer to the session protection 47 negotiation at a lower network layer. The use of channel bindings 48 allows applications to delegate session protection to lower layers. 50 Table of Contents 52 1. Introduction 53 2. Definitions 54 3. Authentication protocols and channel bindings 55 3.1. The GSS-API and channel bindings 56 3.2. SASL and channel bindings 57 3.3. Kerberos V and channel bindings 58 4. Channel bindings to secure layers 59 4.1. Bindings to SSHv2 channels 60 4.2. Bindings to TLS channels 61 4.3. Bindings to IPsec transport mode IKEv2 IKE_SAs 62 4.3.1. Interfaces for creating IPsec channels 63 4.5. Bindings to other types of channels 64 5. Benefits of channel bindings to secure channels 65 6. Security considerations 66 7. References 67 7.1. Informative references 68 7.2. Normative references 69 8. Acknowledgements 70 9. Author's Address 71 Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 1. Introduction 79 [NOTE: This I-D text has been split out from the "The Channel 80 Conjunction Mechanism (CCM) for GSS" I-D, which will be 81 updated soon to define only the CCM-BIND and CCM-MIC GSS-API 82 pseudo-mechanisms and describe their use. CCM-BIND is 83 particularly relevant to the use of channel bindings with 84 GSS-API applications. See draft-ietf-nfsv4-ccm-01.txt.] 86 Over the years several attempts have been made to delegate session 87 protection at one network layer to another, for performance and/or 88 scalability as well as for design elegance and also to avoid having 89 to reinvent the wheel for every new application or security layer. 91 The critical security problem to solve in order to achieve such 92 delegation of session protection is always the same: how to ensure 93 that there is no man-in-the-middle (MITM), from the point of view the 94 application, at the lower network layer to which session protection 95 is to be delegated. 97 Alternative statement of the problem: how does one ensure that the 98 end-points of two secure channels at different network layers are the 99 same? 101 And there may well be a MITM, particularly if the lower network layer 102 either provides no authentication or if there is no connection 103 between the authentication or principals used at the application and 104 those used at the lower network layer. 106 Such MITM attacks can be effected by, for example, spoofing IP 107 address lookups (which is possible, for example, when using DNS but 108 not DNSSEC) in a way that the application may not detect but which 109 directs the client application or network stack to connect to a 110 different host than had been intended (e.g., to the MITM's host). 111 Even if such MITM attacks seem particularly difficult to effect, the 112 problem must be solved. 114 For example: a user decides to use TELNET, with Kerberos V 115 authentication, over TLS to connect to some server but an attacker 116 spoofs the name service lookup and causes the TELNET client to be 117 redirected to some other host which TLS authenticates correctly and 118 where the attacker forwards the connection, with or without TLS, to 119 the server that the user had intended. In this example there is an 120 MITM from the point of view of the application (TELNET), even though 121 there is no MITM as far as TLS is concerned. The TELNET client and 122 server cannot assume that there is no MITM and so cannot leverage the 123 protection afforded by the TLS channel, unless they prove to each 124 other that there is no MITM. 126 A solution to this problem is highly desirable, particularly where 127 multi-user applications are run over secure network layers (e.g., NFS 128 over IPsec). For such applications the authentication model used at 129 the application layer (usually user<->server) is generally very 130 different from that used by secure, lower network layers, such as 131 IPsec (usually client<->server or single-user<->server), and may even 132 use different authentication infrastructures altogether (e.g., 133 Kerberos V for the application layer, x.509 certificates at the lower 134 layer). Such applications cannot generally leverage the security 135 provided by the lower network layers, which, if they could, would 136 allow them to offload session security to the secure lower layer. 138 One solution involves ensuring the use of secure name services for 139 hostname to network address translation and the use of secure 140 networks (e.g., IPsec). This approach can prevent the MITM attack 141 described above, but does not offer applications any guarantees that 142 there is no MITM in the lower layer. 144 Another solution is to use "channel bindings" (a GSS-API concept 145 [RFC2743]) to bind authentication at application layers to secure 146 transports at lower layers in the network stack. This solution is 147 only applicable to applications that provide for user authentication. 149 "Channel bindings" are data which securely identify a secure channel 150 such that, when verified to match on both endpoints of end-to-end 151 application connections, leave no doubt that the endpoints of two 152 secure channels (the one identified by the bindings and the one used 153 to exchange/verify the bindings) are the same. 155 Because many applications exist which provide for authentication at 156 the application layer, because many such applications use generic 157 authentication frameworks, such as the GSS-API and SASL and are 158 already deployed along with a common authentication infrastructure 159 (e.g., Kerberos V, PKI, etc...), because such applications exist 160 which multiplex multiple users onto a single session (and so cannot 161 leverage network [e.g., IKE] authentication), the use of channel 162 bindings is an elegant solution even where secure name services and 163 networks are deployed. 165 A formal definition of the channel bindings concept is given below, 166 as well as the specific formulation of channel bindings for various 167 protocols that provide for session security. 169 2. Definitions 171 The GSS-API [RFC2743] is a generic interface to GSS-API security 172 mechanisms which provides for authentication and session 173 cryptographic protection. One facility provided by the GSS-API is a 174 concept of "channel bindings" which consists of some data which must 175 be provided, if at all, by initiators and acceptors and which the 176 GSS-API security mechanisms ensure are the same for both, the 177 initiator and acceptor of any given GSS-API security context - if 178 the channel bindings provided by them do not match then the mechanism 179 fails to establish a security context. 181 o Channel bindings 183 Some data which identifies a channel. 185 Where channel bindings are used they MUST be exchanged with 186 authenticated integrity protection. 188 o Channel bindings to secure sessions 190 Channel bindings that securely identify a secure channel, such 191 that no two channels of the same type can have the same channel 192 bindings. 194 Applications can exchange authenticated, integrity-protected 195 proofs of their possession of the same channel bindings data to 196 prove that the endpoints of the channel identified by the channel 197 bindings are the same as the application endpoints (and thus, 198 there can be no MITM at the lower layer). 200 More formally, channel bindings to secure sessions 202 - MUST be cryptographically bound to the key exchange of the 203 secure session 205 - MUST be cryptographically bound to all potentially un- 206 authenticated plaintext used for negotiation of the secure 207 session (e.g., algorithm negotiations) 209 and 211 - users of channel bindings MUST exchange authenticated, 212 integrity protected channel bindings data or signatures 213 thereof (such exchanges MAY also be confidentiality 214 protected) 216 Additionally, the channel represented by the bindings MUST provide 217 a cryptographically secure key exchange and channel setup 218 negotiation, and it MUST provide at least cryptographically secure 219 data integrity protection services. 221 Channel bindings data MAY but SHOULD NOT be constructed in such a 222 way that their exchange requires confidentiality protection. 224 No channel bindings described herein require confidentiality 225 protection. 227 The security of channel bindings depends on the security of: 229 - the authentication and integrity protection technology used to 230 protect the channel bindings exchanges at the application 231 layers 233 - the security of the channels identified by the channel bindings 235 - the security of the channel bindings construction 237 o Channel bindings to network addresses 239 The GSS-API originally defined only channel bindings to network 240 addresses. Such channel bindings, of course, are generally not 241 cryptographically secure - this is so even though IPsec, say, can 242 be used to secure communications between to IP nodes, except where 243 the initiators and acceptors using channel bindings to network 244 addresses are able actually confirm and enforce the use of IPsec 245 between them. 247 For channel bindings to network addresses to be secure the 248 application peers MUST be able to verify and ensure that network 249 communications between them are secured and that there is no MITM 250 - which generally means that the application peers MUST be able to 251 interpret and authorize identities authenticated by the network. 253 In practice channel bindings to network addresses have mostly just 254 caused trouble with NATs. 256 3. Authentication protocols and channel bindings 258 Some authentication services provide for channel bindings, such as 259 the GSS-API and some GSS-API mechanisms - others do not, such as 260 SASL. Where suitable channel bindings facilities are not provided 261 application protocol designers may include a separate, protected 262 (where the authentication service provides message protection 263 services) exchange of channel bindings material 265 3.1. The GSS-API and channel bindings 267 The GSS-API provides for the use of channel bindings during 268 initialization of GSS-API security contexts, though GSS-API 269 mechanisms are not required to support this facility. 271 This channel bindings facility is defined in detail in RFC2744. 273 Unfortunately, the use of GSS-API channel bindings is generally not 274 negotiated by GSS-API mechanisms, therefore GSS-API applications must 275 agree a priori on the use of channel bindings or otherwise negotiate 276 the use of channel bindings. 278 Fortunately, it is possible to design GSS-API pseudo-mechanisms that 279 simply wrap around existing mechanisms for the purpose of allowing 280 applications to negotiate the use of channel bindings within their 281 existing methods for negotiating GSS-API mechanisms. For example, 282 NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as 283 does the MOUNT protocol for NFSv2/3 [RFC....]. [NOTE: This is an 284 indirect reference to the Channel Conjunction Mechanism (CCM).] 286 3.2. SASL and channel bindings 288 SASL does not provide for the use of channel bindings during 289 initialization of SASL contexts. 291 SASL applications MAY define their own exchange of integrity- 292 protected channel bindings using established SASL integrity layers. 294 Alternatively, SASL applications MAY use the GSS-* SASL mechanisms 295 (which correspond to GSS-API mechanisms) to ensure the use of channel 296 bindings through the GSS-API's facilities. 298 3.3. Kerberos V and channel bindings 300 Kerberos V does not provide for use of channel bindings, thus the 301 same general approach given above (post-authentication protected 302 channel bindings exchange) applies to Kerberos V as well. 304 However, Kerberos V AP client applications also MAY use the AP-REQ's 305 Authenticator's "checksum" field to send a hash of channel bindings 306 material to Kerberos V AP servers. Unfortunately, there is no slot 307 in the AP-REP message for carrying the AP server's channel bindings 308 (which justifies the statement that Kerberos V does not provide a 309 channel bindings facility), so Kerberos V applications MUST establish 310 a convention with regards to AP servers' handling of AP-REQ checksum 311 data - and such applications have to trust the servers to respond 312 with suitable error messages to AP-REQs bearing incorrect channel 313 bindings. 315 4. Channel bindings to secure layers 317 Not every secure session protocol or interface provides for secure 318 channels, and not every secure session protocol provides data 319 suitable for use as channel bindings. 321 4.1. Bindings to SSHv2 channels 323 SSHv2 provides both, a secure channel and material (the SSHv2 324 "session ID") that is suitable for use as channel bindings. 326 Thus it is RECOMMENDED that the SSHv2 "session ID" be used as the 327 channel bindings for SSHv2. 329 4.2. Bindings to TLS channels 331 TLS provides both, a secure channel and material (the TLS "finished" 332 messages), that is suitable for use as channel bindings. 334 Thus it is RECOMMENDED that the concatenation of the client's and 335 server's "finished" messages, in that order, be used as the channel 336 bindings for TLS. 338 Note that the TLS "session ID," in spite of being named similarly to 339 the SSHv2 session ID, is not suitable for use as channel bindings 340 because it is assigned by the server, so a MITM could assign the same 341 session ID on the client side as it gets from the server. 343 4.3. Bindings to IPsec transport mode IKEv2 IKE_SAs 345 IPsec does not provide either a channel or material suitable for use 346 as channel bindings. However, it is possible to construct IPsec 347 channels with a simple programming interface for binding connection- 348 oriented transports to transport mode SAs, and it is possible to 349 construct channel bindings for IKEv2 IKE_SAs. 351 The RECOMMENDED channel bindings for IKEv2 IKE_SAs consist of a SHA-1 352 hash of the concatenation of the octets normally signed by the IKEv2 353 initiator and responder, in that order, in the AUTH payloads of the 354 IKEv2 SA exchange for the initial (i.e., non-rekeyed) transport-mode 355 IKE_SA that corresponds to the SA that a connection is being bound 356 to. 358 4.3.1. Interfaces for creating IPsec channels 360 In order to build an IPsec channel some additional programming 361 interfaces are needed. Specifically, an interface is needed to 362 express an application's desire to bind an as yet unconnected 363 connection-oriented endpoint to an IKEv2 IKE_SA, as well as the 364 application's desired binding parameters, plus an interface to query 365 a connected endpoint to examine if the binding to IPsec succeeded as 366 well as to obtain the necessary channel bindings. 368 Two forms of transport binding to IPsec are possible: a) binding to 369 an IKE_SA irrespective of authenticated identities, b) binding to 370 IKEv2 authenticated identities. Applications MAY request neither, 371 either or both of these. Additionally, applications MUST request 372 integrity or confidentiality protection (the latter MUST imply the 373 former) and MAY limit the set of IPsec integrity and/or 374 confidentiality protection algorithms, acceptable key lengths, etc... 375 Together these items constitute the connection binding parameters. 377 Applications MUST agree a priori, whether by design, configuration or 378 through some other form of out-of-band negotiation, on compatible 379 binding parameters. This is because existing connection-oriented 380 transport protocols, such as TCP and SCTP, do not provide for 381 negotiation of IPsec connection binding parameters, therefore, if the 382 applications do not agree a priori, they will fail to interoperate. 383 Note also that the binding status of an established connection cannot 384 be changed without support for such binding negotiation in the 385 transport protocol. 387 When a connection-oriented transport is bound to IPsec the host MUST 388 NOT send or process any IP packets for that connection protected with 389 any SA which either: a) is not the IKE_SA that the connection was 390 bound to (or an SA that was derived therefrom in a cryptographically 391 secure manner, such as through IKEv2 rekeying, or a CHILD_SA), b) 392 does not authenticate the same IKEv2 identities that were bound to, 393 or c) does not provide the protection service requested by the 394 application. That is, the host MUST enforce the connection binding 395 requirements of its applications. Server hosts determine the IKE_SA 396 and/or IKEv2 IDs to which new connections are bound by inspection of 397 the SA used to protect the initial packet for each new connection. 399 In terms of the familiar sockets APIs this means having a socket 400 option to set on sockets prior to calling connect() or listen() and 401 an socket option (perhaps the same option) to get the binding 402 state and channel bindings after a socket has been connect()ed or 403 accept()ed. The programming language-specific details of these 404 interfaces are not specified here. 406 More formally the following APIs are needed: 408 - An interface for indicating an application's desired connection 409 binding parameters: 411 - 'BINDING_TYPE', the type of binding, either or both of: 413 - 'IKE_SA_BINDING', an IKE_SA, not identified by the 414 application, and its rekeyed and CHILD_SA successors 416 and/or 418 - 'IKE_ID_BINDING', IKEv2 authenticated identities, 419 optionally specified by the application 421 - 'BINDING_PROT', the payload protection service desired, that 422 is, integrity or confidentiality and integrity protection 424 - 'BINDING_PROT_ALGS', the acceptable protection service 425 algorithms and algorithm parameters 427 such that, once bound, no messages are sent, and no received 428 messages are processed, for the given connection that are not 429 protected by an SA that satisfies the binding requirements. 431 Unspecified binding parameters (the IKE_SA and/or IKEv2 432 authenticated IDs) are established by the first message sent 433 (client-side) or received (server-side) for a connection to be 434 bound. For example, for TCP connections, the binding parameters 435 are those of the SA selected for protecting the TCP SYN packet). 437 Applications MUST agree a priori on the connection binding 438 parameters to use (except for the BINDING_PROT_ALGS parameter, 439 where the server-side MAY specify a super-set of the client's 440 BINDING_PROT_ALGS). Applications MAY leave BINDING_PROT_ALGS 441 unspecified, leaving the SPD as the control of what algorithms 442 are used. 444 - An interface for querying the binding state of a connection 445 (i.e., "is this connection bound to IPsec?"). 447 - An interface for querying the channel bindings of a connection's 448 IKE_SA binding. 450 - An interface for querying the identities authenticated by IKEv2 451 for the bound SAs. 453 Connection binding can fail when bound IKE_SAs fail to rekey 454 properly, when bound identities' credentials expired, or when there 455 is disagreement, between client and server, on what type of 456 connection binding, if any, is to be used. Implementations of 457 connection binding MUST cause the connection to reset or to hang 458 under any of these conditions, but MUST specify which behaviour 459 results so that applications may detect connection failure and act as 460 appropriate. 462 Note that where applications bind application-layer authentication to 463 IKE_SAs, but not IKEv2 IDs, there is an optimization whereby the 464 IKEv2 IKE_SA need not be authenticated. That is, the use of 465 authentication at the application layer with channel bindings to 466 IKE_SAs gives meaning to "anonymous IPsec," thus enabling the use of 467 such applications with IPsec and without having to deploy an IKEv2 468 authentication infrastructure (for those applications). 470 Connection binding to IPsec does not require changes to the IPsec SPD 471 model, though the "bypass" and "apply" actions of SPD entries are 472 irrelevant to connections bound to IPsec - the "discard" action and 473 any actions selecting or constraining the usable integrity and 474 confidentiality algorithms that can be used still apply. 476 4.5. Bindings to other types of channels 478 For secure session protocols that do not provide material suitable 479 for use as channel bindings such material SHOULD be constructed by 480 concatenating the octets from the messages exchanged during the 481 initialization of a session in the chronological order in which they 482 were exchanged and processed (which requires synchronous session 483 initialization), or a strong hash thereof (such as SHA-1). 485 Some secure session protocols do not provide a secure channel but 486 which do provide per-message integrity or confidentiality protection 487 services. It is up to the network layers that use such protocols to 488 build channels from such services; applications MUST NOT delegate 489 session cryptographic protection to network layers that do not 490 provide a secure channel. 492 Kerberos V, certain GSS-API and SASL mechanisms, all provide session 493 cryptographic protection and the necessary key exchange, but they 494 provide neither a channel nor material suitable for use as channel 495 bindings. 497 Thus the RECOMMENDED channel bindings for channels protected by 498 Kerberos V consist of a SHA-1 hash of the concatenated octets of the 499 AP-REQ and AP-REP messages, in that order (or, for user-to-user 500 exchanges, the various messages exchanged, including the ticket 501 request, ticket and AP messages, in the order in which they were 502 generated and processed) used to initialize the channel's 503 cryptographic protection. 505 Similarly for channels protected by GSS-API security contexts the 506 RECOMMENDED channel bindings consist of a SHA-1 hash of the 507 concatenated octets of the context tokens exchanged to setup a 508 GSS-API security context in the order in which they were generated 509 and processed (i.e., starting with the initiator's initial context 510 token followed by the acceptor's reply token, if any, followed by the 511 initiator's reply token, if any, etc...). 513 5. Benefits of channel bindings to secure channels 515 The use of channel bindings to delegate session cryptographic 516 protection include: 518 o Performance improvements by avoiding double protection in cases 519 where IPsec is in use and applications provide their own secure 520 channels. 522 o Performance improvements by leveraging hardware-accelerated IPsec. 524 o Performance improvements by allowing RDMA hardware offloading to 525 be integrated with IPsec hardware acceleration. 527 o Latency improvements for applications that multiplex multiple 528 users onto a single channel, such as NFS w/ RPCSEC_GSS. 530 6. Security considerations 532 When delegating session protection from one layer to another, one 533 will almost certainly be making some session security trade-offs, 534 such as using weaker data encryption/authentication modes. 535 Implementors and administrators SHOULD understand these trade-offs. 537 Channel bindings cannot and MUST NOT be used without mutual 538 authentication (of client/user/initiator and server/user/acceptor) 539 and/or without integrity-protected, authenticated exchange of channel 540 bindings material. 542 Anonymous secure channels SHOULD NOT be used without authentication 543 and corresponding use of channel bindings (to the anonymous secure 544 channels) at higher network layers, or for any purposes other than 545 opportunistic encryption, since such channels provide no 546 authenticated protection on their own. 548 The security of channel bindings depends on the security of the 549 channels, the construction of the bindings and the security of the 550 authentication and integrity protection used to exchange channel 551 bindings. 553 7. References 555 7.1. Informative references 557 [Needs references to NFSv2/3 use of RPCSEC_GSS, to NFSv4, to SCTP, 558 and, possibly, to DNS, DNSSEC, TELNET, SPNEGO, SSHv2 gss keyex, and 559 CCM.] 561 [TELNET] 562 J. Postel, J.K. Reynolds, RFC0854 (STD0008): "Telnet Protocol 563 Specification," May 1993, Status: Standard. 565 [DNS] 566 P.V. Mockapetris, RFC1035 (STD0013): "Domain names - 567 implementation and specification," November 1987, Status: 568 Standard. 570 [DNSSEC] 571 B. Wellington, RFC3008: "Domain Name System Security (DNSSEC) 572 Signing Authority," November 2000, Status: Proposed Standard. 574 [RFC2203] 575 M. Eisler, A. Chiu, L. Ling, RFC2203: "RPCSEC_GSS Protocol 576 Specification," September 1997, Status: Proposed Standard. 578 [RFC2623] 579 M. Eisler, "NFS Version 2 and Version 3 Security Issues and the 580 NFS Protocol's Use of RPCSEC_GSS and Kerberos V5," June 1999, 581 Status: Proposed Standard. 583 [NFSv4] 584 S. Shepler, et. al., RFC3530: "Network File System (NFS) version 4 585 Protocol," April 2003, Status: Proposed Standard. 587 [SPNEGO] 588 E. Baize, D. Pinkas, RFC2478: "The Simple and Protected GSS-API 589 Negotiation Mechanism," December 1998, Status: Proposed Standard. 591 [CCM] 592 M. Eisler, N. Williams, Internet-Draft: "The Channel Conjunction 593 Mechanism (CCM) for GSS," May 2003, Status: Internet-Draft. 595 ... 597 7.2. Normative references 599 [Needs references to RFC2119, RFC2026, the GSS-API (RFCs 2743 & 600 2744), SASL, SSHv2, IKEv2, IPsec, TCP, Kerberos V, SHA-1.] 602 [RFC2026] 603 S. Bradner, RFC2026: "The Internet Standard Process - Revision 604 3," October 1996, Obsoletes - RFC 1602, Status: Best Current 605 Practice. 607 [RFC2119] 608 S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to 609 Indicate Requirement Levels," March 1997, Status: Best Current 610 Practice. 612 [RFC2743] 613 J. Linn, RFC2743: "Generic Security Service Application Program 614 Interface Version 2, Update 1," January 2000, Status: Proposed 615 Standard. 617 [RFC2744] 618 J. Wray, RFC2744: "Generic Security Service API Version 2 : 619 C-bindings," January 2000, Status: Proposed Standard. 621 [TCP] 622 J. Postel, RFC0793 (STD0007): "Transmission Control Protocol," 623 September 1981, Status: Standard. 625 ... 627 8. Acknowledgements 629 The author would like to thank Mike Eisler for his work on the 630 Channel Conjunction Mechanism I-D and for bringing the problem to a 631 head, Sam Hartman for pointing out that channel bindings provide a 632 general solution to the channel binding problem, Jeff Altman for his 633 suggestion of using the TLS finished messages as the TLS channel 634 bindings, as well as Bill Sommerfeld, Radia Perlman for their most 635 helpful comments. 637 9. Author's Address 639 Nicolas Williams 640 Sun Microsystems 641 5300 Riata Trace Ct 642 Austin, TX 78727 643 Email: nicolas.williams@sun.com 645 Full Copyright Statement 647 Copyright (C) The Internet Society (2003). All Rights Reserved. 649 This document and translations of it may be copied and furnished to 650 others, and derivative works that comment on or otherwise explain it 651 or assist in its implementation may be prepared, copied, published 652 and distributed, in whole or in part, without restriction of any 653 kind, provided that the above copyright notice and this paragraph are 654 included on all such copies and derivative works. However, this 655 document itself may not be modified in any way, such as by removing 656 the copyright notice or references to the Internet Society or other 657 Internet organizations, except as needed for the purpose of 658 developing Internet standards in which case the procedures for 659 copyrights defined in the Internet Standards process must be 660 followed, or as required to translate it into languages other than 661 English. 663 The limited permissions granted above are perpetual and will not be 664 revoked by the Internet Society or its successors or assigns. 666 This document and the information contained herein is provided on an 667 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 668 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 669 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 670 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 671 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 673 Acknowledgement 675 Funding for the RFC Editor function is currently provided by the 676 Internet Society.