Network Working Group                                   NicolasNETWORK WORKING GROUP                                        N. Williams
INTERNET-DRAFT
Internet-Draft                                                       Sun Microsystems
                                                           November
Expires: January 13, 2005                                  July 15, 2004

           On the Use of Channel Bindings to Secure Channels
              <draft-ietf-nfsv4-channel-bindings-01.txt>
                draft-ietf-nfsv4-channel-bindings-02.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of Section 10 which I am aware have been disclosed,
   and any of RFC2026. which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-
   Drafts Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 13, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document defines and formalizes the concept of channel bindings
   to secure layers and defines the actual contents of channel bindings for several types
   of secure channels.

   The concept of channel bindings allows applications to prove that the
   end-points of two secure channels at different network layers are the
   same by binding authentication at one network layer channel to the session
   protection
   negotiation at a lower network layer. the other channel.  The use of channel bindings allows
   applications to delegate session protection to lower layers.

N. Williams							[Page 1]

DRAFT		Channel Bindings to Secure Channels	Expires November 2004 layers, which
   may significantly improve performance for some applications.

Table of Contents

   1.       Introduction                                    pg.  Conventions used in this document  . . . . . . . . . . . . . .  3
   2.       Definitions                                     pg.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Authentication protocols and channel bindings   pg. 6
   3.1.  . . . . . . . .  7
     4.1   The GSS-API and channel bindings                pg. 6
   3.2.     SASL and channel bindings                       pg. . . . . . . . . . . . . .  7
   3.3.     Kerberos V
     4.2   SASL and channel bindings                 pg.  . . . . . . . . . . . . . . . .  7
   4.
   5.  Channel bindings to for various secure layers               pg. 7
   4.1. . . . . . . . . . .  8
     5.1   Bindings to SSHv2 channels                      pg. 7
   4.2. . . . . . . . . . . . . . . . .  8
     5.2   Bindings to TLS channels                        pg. 7
   4.3. . . . . . . . . . . . . . . . . .  8
     5.3   Bindings to IPsec                               pg.  . . . . . . . . . . . . . . . . . . . .  8
   4.3.1.
       5.3.1   Interfaces for creating IPsec channels          pg. 8
   4.4. . . . . . . . .  9
     5.4   Bindings to other types of channels             pg.  . . . . . . . . . . .  9
   5.
   6.  Benefits of channel bindings to secure channels pg. 9
   6.       Security considerations                         pg.  . . . . . . . 10
   7.       References                                      pg. 10
   7.1.     Informative references                          pg. 10
   7.2.     Normative references                            pg.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.       Acknowledgements                                pg.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.1   Normative  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.2   Informative  . . . . . . . . . . . . . . . . . . . . . . . . 12
   9.
       Author's Address                                pg. . . . . . . . . . . . . . . . . . . . . . . . 12

N. Williams							[Page 2]

DRAFT		Channel Bindings to Secure Channels	Expires November 2004
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14

1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.

2.  Introduction

   [NOTE:  This I-D text has been split out from the "The Channel
	   Conjunction Mechanism (CCM) for GSS" I-D, which will be
	   updated soon to define only the CCM-BIND and CCM-MIC GSS-API
	   pseudo-mechanisms and describe their use.  CCM-BIND is
	   particularly relevant to the use of channel bindings with
	   GSS-API applications.  See draft-ietf-nfsv4-ccm-01.txt.]

   Over the years several attempts have been made to delegate session
   protection at one network layer to another, for performance and/or
   scalability as well as for design elegance and also to avoid having
   to reinvent the wheel (that is, cryptographic session protection) for
   every new application or security layer.

   The critical security problem to solve in order to achieve such
   delegation of session protection is always the same: how to ensure
   that there is no man-in-the-middle (MITM), from the point of view the
   application, at the lower network layer to which session protection
   is to be delegated.

   Alternative

   An alternative statement of the problem: how does one ensure that the
   end-points of two secure channels at different network layers are the
   same?

   And there may well be a MITM, particularly if the lower network layer
   either provides no authentication or if there is no connection
   between the authentication or principals used at the application and
   those used at the lower network layer.

   Such MITM attacks can be effected by, for example, spoofing IP
   address lookups (which is possible, for example, when using DNS but
   not DNSSEC) in a way that the application may not detect but which
   directs the client application or network stack to connect to a
   different host than had been intended (e.g., to the MITM's host).

   Even if such MITM attacks seem particularly difficult to effect, the
   problem
   attacks must be solved.

   For example: a user decides to use TELNET, with Kerberos V
   authentication, over TLS to connect to some server but an attacker
   spoofs the name service lookup and causes the TELNET client prevented for certain applications to be
   redirected able to some other host which TLS authenticates correctly and
   where the attacker forwards the connection, with or without TLS, make
   effective use of technologies such as IPsec.

   A solution to
   the server that the user had intended.  In this example there problem is an
   MITM from the point of view of the application (TELNET), even though
   there is no MITM as far as TLS is concerned.  The TELNET client and

N. Williams							[Page 3]

DRAFT		Channel Bindings to Secure Channels	Expires November 2004

   server cannot assume that there is no MITM and so cannot leverage the
   protection afforded by the TLS channel, unless they prove to each
   other that there is no MITM.

   A solution to this problem is highly desirable, particularly where
   multi-user applications are run over secure network layers (e.g., NFS
   over IPsec).  For such applications highly desirable, particularly where
   multi-user applications are run over secure network layers (e.g., NFS
   over IPsec).  For such applications the authentication model used at
   the application layer (usually user<->server) is generally very
   different from that used by secure, lower network layers, such as
   IPsec (usually client<->server or single-user<->server), and may even
   use different authentication infrastructures altogether (e.g.,
   Kerberos V for the application layer, x.509 certificates at the lower
   layer).  Such applications cannot cannot, at present, generally leverage the
   security provided by the lower network layers, which, if they could,
   would allow them to offload session security to the secure lower
   layer.

   One solution involves ensuring the use of secure name services for
   hostname to network address translation and along with the use of secure
   networks (e.g., IPsec).  This approach can prevent the MITM attack
   described above, but does not offer applications any guarantees that
   there is no MITM in the lower layer.

   Another solution is to

   This document describes another solution: the use of "channel
   bindings" (a GSS-API concept [RFC2743]) to bind authentication at
   application layers to secure transports at lower layers in the
   network stack.  This solution is
   only applicable to applications that provide for user authentication.

   "Channel bindings" are data which securely identify a secure channel
   such that, when verified to match on both endpoints of end-to-end
   application connections, leave no doubt that the endpoints of two
   secure channels (the one identified by the bindings and the one used
   to exchange/verify the bindings) are the same.

   Because many applications exist which provide for authentication at
   the application layer, because many such applications use generic
   authentication frameworks, such as the GSS-API and SASL and are
   already deployed along with a common authentication infrastructure
   (e.g., Kerberos V, PKI, etc...), because such applications exist
   which multiplex multiple users onto a single session (and so cannot
   leverage network [e.g., IKE] authentication), the use of channel
   bindings is an elegant solution even where secure name services and
   networks are deployed.

   A formal definition of the channel bindings concept is given below,
   as well as the specific formulation of channel bindings for various
   protocols that provide for session security.

2.

   Specific instructions for the use of channel bindings with GSS-API
   instructions is given elsewhere.

3.  Definitions

   The GSS-API [RFC2743] is a generic interface to GSS-API security
   mechanisms which provides for authentication and session
   cryptographic protection.  One facility provided by the GSS-API is a
   concept of "channel bindings" which consists of some data which must

N. Williams							[Page 4]

DRAFT		Channel Bindings to Secure Channels	Expires November 2004
   be provided, if at all, by both, initiators and acceptors acceptors, and which
   the GSS-API security mechanisms ensure are the same for both, the
   initiator and acceptor of any given GSS-API security context - if the
   channel bindings provided by them do not match then the mechanism
   fails to establish a the security context.

   o  Channel bindings
         Generally some data which names a channel or its end-points.

   o  Channel bindings to secure channels

      Channel bindings that securely identify a secure channel or its
      end-points.

      Applications can exchange authenticated, integrity-protected
      verifiers of their same
         The security properties and channel bindings data to prove that the
      end-points of the channel identified by the channel bindings are
      the same as channel,
         once established, MUST NOT change for the application endpoints and thus, there can be no
      MITM at lifetime of the lower layer.
         channel.

         More formally, there are two types of channel bindings:

       -

         +  bindings that name a channel in a cryptographically secure
            manner (e.g., the session ID in SSHv2; see below)

       - below);
         +  bindings that name the authenticated end-points of a channel
            (e.g., as in IPsec; see below)

	 Bindings that name a channel

	  - MUST be cryptographically bound to the key exchange of the
	    secure session

	  - MUST be cryptographically which are, in turn, securely
            bound to all potentially un-
	    authenticated plaintext used for negotiation of the secure
	    session (e.g., algorithm negotiations)

      and

       - users of channel bindings MUST channel.

         Applications can exchange authenticated,
	 integrity protected integrity-protected
         verifiers of channel bindings data or signatures thereof
	 (such exchanges MAY also be confidentiality protected)

      Additionally, to prove that the end-points
         of some channel represented by are the bindings MUST provide
      a cryptographically secure key exchange (and re-keying) and
      channel setup negotiation, and it MUST provide at least
      cryptographically secure data integrity protection services.

      Channel bindings data SHOULD NOT be constructed in such a way that
      their exchange requires confidentiality protection.

N. Williams							[Page 5]

DRAFT		Channel Bindings to Secure Channels	Expires November 2004

      No channel bindings described herein require confidentiality
      protected exchanges.

      The security of channel bindings depends on logically the security of:

       - same as the authentication application
         endpoints and integrity protection technology used to
	 protect the channel bindings exchanges thus, there can be no MITM at the application
	 layers

       - the security of the channels identified by the channel bindings

       - the security of the channel bindings construction lower layer.
   o  Channel bindings to network addresses
         The GSS-API originally defined only channel bindings to network
         addresses.  Such channel bindings, of course, are generally not
      cryptographically secure.

      For channel bindings to
         The network addresses to be secure of a channel's end-points typically say
         nothing about the
      application peers MUST be able to verify and ensure protection afforded by that network
      communications between them are secured channel, and that there is no MITM
      - which generally means that
         where the application peers MUST channel can be able said to
      interpret and authorize identities authenticated by the network
      and MUST be able to protect the methods by which they obtain secure the network
         addresses in may not be securely bound to the first place. channel anyways.
         In practice channel bindings to network addresses have mostly
         just caused trouble with Network Address Translation (NAT).

3.

4.  Authentication protocols and channel bindings

   Some authentication services provide for channel bindings, such as
   the GSS-API and some GSS-API mechanisms - mechanisms, whereas others do may not, such
   as SASL.

   Where suitable channel bindings facilities are not provided
   application protocol designers may include a separate, protected
   (where the authentication service provides message protection
   services) exchange of channel bindings material

3.1. material.

4.1  The GSS-API and channel bindings

   The GSS-API provides for the use of channel bindings during
   initialization of GSS-API security contexts, though GSS-API
   mechanisms are not required to support this facility.

   This channel bindings facility is defined described in detail in RFC2744.

   Unfortunately, the use of GSS-API channel bindings is generally not
   negotiated by GSS-API mechanisms, therefore

   GSS-API applications must agree a priori priori, through negotiation or
   otherwise, on the use of channel bindings or otherwise negotiate bindings.  This is because the
   GSS-API does not have a way to indicate that a security context was
   successfully established but that the use of channel bindings.

N. Williams							[Page 6]

DRAFT		Channel Bindings bindings supplied could
   not be verified to Secure Channels	Expires November 2004 be the same for both peers.

   Fortunately, it is possible to design GSS-API pseudo-mechanisms that
   simply wrap around existing mechanisms for the purpose of allowing
   applications to negotiate the use of channel bindings within their
   existing methods for negotiating GSS-API mechanisms.  For example,
   NFSv4 [RFC3530] provides its own GSS-API mechanism negotiation, as
   does the MOUNT SSHv2 protocol for NFSv2/3 [RFC....]. [SECSH-GSSAPI].  Such pseudo-mechanisms are
   being proposed separately.  [NOTE:  This is an
   indirect  Indirect reference to the Channel Conjunction Mechanism (CCM).]

3.2. CCM...]

   However, it does not, at this time, seem feasible to use SPNEGO with
   such pseudo-mechanisms for negotiating the use of channel bindings.

4.2  SASL and channel bindings

   SASL does not provide for the use of channel bindings during
   initialization of SASL contexts.

   SASL applications MAY define their own exchange of integrity-
   protected channel bindings using established SASL integrity layers.

   Alternatively, SASL applications MAY use the GSS-* SASL mechanisms
   (which correspond to GSS-API mechanisms) to ensure the use of channel
   bindings through the GSS-API's facilities.

3.3.    Kerberos V and channel bindings

   Kerberos V does not provide for use of channel bindings, thus the
   same general facilities; this approach given above (post-authentication protected
   channel bindings exchange) applies to Kerberos V as well.

   However, Kerberos V AP client applications also MAY use the AP-REQ's
   Authenticator's "checksum" field to send a hash of channel bindings
   material to Kerberos V AP servers.  Unfortunately, there is no slot
   in the AP-REP message for carrying the AP server's channel bindings
   (which justifies the statement that Kerberos V does not provide a
   channel bindings facility), so Kerberos V applications MUST establish
   a convention with regards to AP servers' handling of AP-REQ checksum
   data - may require
   more study and such applications have to trust the servers to respond
   with suitable error messages to AP-REQs bearing incorrect channel
   bindings.

4. specification elsewhere.

5.  Channel bindings to for various secure layers

   Not every secure session protocol or interface provides for secure
   channels, and not every secure session protocol provides data
   suitable for use as channel bindings.

4.1.

5.1  Bindings to SSHv2 channels

   SSHv2 provides both, a secure channel and material (the SSHv2
   "session ID") that is suitable for use as channel bindings.

   Thus it is RECOMMENDED that the SSHv2 "session ID" be used as the
   channel bindings for SSHv2.

4.2.

5.2  Bindings to TLS channels

N. Williams							[Page 7]

DRAFT		Channel Bindings to Secure Channels	Expires November 2004

   TLS provides both, a secure channel and material (the TLS "finished"
   messages), that is suitable for use as channel bindings.

   Thus it is RECOMMENDED that the concatenation of the client's and
   server's "finished" messages, in that order, be used as the channel
   bindings for TLS.

   Note that the TLS "session ID," in spite of being named similarly to
   the SSHv2 session ID, is not suitable for use as channel bindings
   because it is assigned by the server, so a MITM could assign the same
   session ID on the client side as it gets from the server.

4.3.

5.3  Bindings to IPsec

   IPsec does not provide a way for secure channels by itself, as it protects
   individual packets.  Further, the IPsec SAs used to reliably name a channel regardless of
   what key exchange protocol is used.

   Therefore, protect the only reliable
   packets for some channel (e.g., a TCP connection) need not be related
   in any way to construct that allows for construction of channel bindings to
   IPsec bindings.

   There is to use a set of IPsec parameters that may be kept constant for all
   IP packets for a given channel (e.g., a TCP connection):

   o  the identities peers' authenticated by IPsec IDs
   o  the SA types (e.g., transport mode ESP)
   o  the privacy and integrity protection algorithms used

      [QUESTION:  Should IPsec key
   exchange traffic selectors, that is, the protocol
      (TCP, UDP, SCTP) and port numbers used for the given channel.

   New channel be
      included?]

   Provided interfaces [IPSP-APIREQ] are required by which applications can
   create for binding a channel to these IPsec "channels."

   The basic idea parameters
   it is possible to use the interfaces described in [IPSP-APIREQ] to
   dynamically alter construct a channel secured by IPsec.

   The channel bindings for such a channel, then, are the SPD values of
   those IPsec parameters to reflect which the requested bindings channel is bound.

   Requirements for the
   requested connections and then use the authenticated IDs as the
   identity of the channel.

   This approach does not name the channel directly, but no MITM can
   ensure that the authenticated IDs used as channel bindings match on
   both end-points unless the MITM has stolen or broken the such interfaces to IPsec
   credentials and/or authentication protocol.  This is sufficient.

4.3.1. are specified in
   [IPSP-APIREQ].

5.3.1  Interfaces for creating IPsec channels

   In order to build an IPsec channel some additional application
   programming interfaces are needed to:

    -

   o  indicate that an as yet unconnected channel is to be bound to
      IPsec IDs and

       -
   o  explicitly specify one, the other or both of those IDs
       -
   o  implicitly specify one, the other or both of those IDs (e.g., the
      ID corresponding to the current application program instance)
       -
   o  indirectly specify one, the other or both of those IDs (e.g., a
	 hostname)
      through IP addresses or hostnames)

   and/or

    -

   o  discover the IPsec IDs to which a channel is bound

N. Williams							[Page 8]

DRAFT		Channel Bindings to Secure Channels	Expires November 2004

   For connection-less datagram transports the IDs to be used need to be
   specified/discovered on a per-datagram basis.

   See [IPSP-APIREQ].

4.4.

5.4  Bindings to other types of channels

   For secure session protocols that do not provide material suitable
   for use as channel

   Channel bindings such material SHOULD be constructed by
   concatenating the octets from the messages exchanged during the
   initialization of a session in the chronological order in which they
   were exchanged and processed (which requires synchronous session
   initialization), or a strong hash thereof (such as SHA-1).

   Some for other secure session protocols do not provide a secure channel but
   which do provide per-message integrity or confidentiality protection
   services.  It is up to the network layers that use such protocols to
   build channels from such services; applications MUST NOT delegate
   session cryptographic protection to network layers that do are not
   provide a secure channel.

   Kerberos V, certain GSS-API and SASL mechanisms, all provide session
   cryptographic protection and the necessary key exchange, but they
   provide neither a channel nor material suitable for use as channel
   bindings.

   Thus the RECOMMENDED channel bindings for channels protected by
   Kerberos V consist of a SHA-1 hash of the concatenated octets of the
   AP-REQ and AP-REP messages, in that order (or, for user-to-user
   exchanges, the various messages exchanged, including the ticket
   request, ticket and AP messages, in the order in which they were
   generated and processed) used to initialize the channel's
   cryptographic protection.

   Similarly for channels protected by GSS-API security contexts the
   RECOMMENDED channel bindings consist of a SHA-1 hash of the
   concatenated octets of the context tokens exchanged to setup a
   GSS-API security context in the order in which they were generated
   and processed (i.e., starting with the initiator's initial context
   token followed by the acceptor's reply token, if any, followed by the
   initiator's reply token, if any, etc...).

5. specified
   here.

6.  Benefits of channel bindings to secure channels

   The use of channel bindings to delegate session cryptographic
   protection include:

   o  Performance improvements by avoiding double protection of
      application data in cases where IPsec is in use and applications
      provide their own secure channels.
   o  Performance improvements by leveraging hardware-accelerated IPsec.

N. Williams							[Page 9]

DRAFT		Channel Bindings to Secure Channels	Expires November 2004
   o  Performance improvements by allowing RDDP hardware offloading to
      be integrated with IPsec hardware acceleration.  If
         Where protocols layered above RDDP use privacy protection then RDDP
         offload cannot be done, thus by using channel bindings to IPsec
         the privacy protection is moved to IPsec, which is layered
         below RDDP, so RDDP can address application protocol data
         that's in cleartext relative to the RDDP headers.
   o  Latency improvements for applications that multiplex multiple
      users onto a single channel, such as NFS w/ RPCSEC_GSS.

6.

7.  Security considerations Considerations

   When delegating session protection from one layer to another, one
   will almost certainly be making some session security trade-offs,
   such as using weaker data encryption/authentication modes. cipher modes in one layer than might be used in
   the other.  Implementors and administrators SHOULD understand these
   trade-offs.

   Channel bindings cannot and MUST NOT be used without mutual
   authentication (of client/user/initiator and server/user/acceptor)
   and/or without integrity-protected, authenticated exchange of channel
   bindings material. server/user/acceptor).

   Anonymous secure channels SHOULD NOT be used without authentication
   and corresponding use of their channel bindings (to the anonymous secure
   channels) at higher network layers, or for any purposes other than
   opportunistic encryption, since such channels provide no
   authenticated protection on their own.
   layers.

   The security of channel bindings depends on the security of the
   channels, the construction of the bindings and the security of the
   authentication and integrity protection used to exchange channel
   bindings.

7.

8.  References

7.1.    Informative references

   [Needs references to NFSv2/3

8.1  Normative

   [RFC2119]  Bradner, S., "Key words for use of RPCSEC_GSS, to NFSv4, to SCTP,
    and, possibly, in RFCs to DNS, DNSSEC, TELNET, SPNEGO, SSHv2 gss keyex, Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.

   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
              C-bindings", RFC 2744, January 2000.

8.2  Informative

   [RFC0854]  Postel, J. and
    CCM.]

   [TELNET] J. Postel, J.K. Reynolds, RFC0854 (STD0008): "Telnet Protocol
      Specification,"
              Specification", STD 8, RFC 854, May 1993, Status: Standard.

   [DNS]
      P.V. 1983.

   [RFC1035]  Mockapetris, RFC1035 (STD0013): P., "Domain names - implementation and specification," November 1987, Status:
      Standard.

   [DNSSEC]

N. Williams							[Page 10]

DRAFT		Channel Bindings to Secure Channels	Expires November 2004

      B. Wellington, RFC3008: "Domain Name System Security (DNSSEC)
      Signing Authority,"
              specification", STD 13, RFC 1035, November 2000, Status: Proposed Standard. 1987.

   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
              (SPKM)", RFC 2025, October 1996.

   [RFC2203]
      M.  Eisler, A. M., Chiu, A. and L. Ling, RFC2203: "RPCSEC_GSS Protocol
      Specification,"
              Specification", RFC 2203, September 1997, Status: Proposed Standard. 1997.

   [RFC2478]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
              Negotiation Mechanism", RFC 2478, December 1998.

   [RFC2623]
      M.  Eisler, M., "NFS Version 2 and Version 3 Security Issues
              and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5," V5",
              RFC 2623, June 1999,
      Status: Proposed Standard.

   [NFSv4]
      S. 1999.

   [RFC3530]  Shepler, et. al., RFC3530: "Network File System (NFS) version 4
      Protocol," April 2003, Status: Proposed Standard.

   [SPNEGO]
      E. Baize, D. Pinkas, RFC2478: "The Simple and Protected GSS-API
      Negotiation Mechanism," December 1998, Status: Proposed Standard.

   [CCM]
      M. S., Callaghan, B., Robinson, D., Thurlow, R.,
              Beame, C., Eisler, N. Williams, Internet-Draft: "The Channel Conjunction
      Mechanism (CCM) for GSS," May 2003, Status: Internet-Draft.

   ...

7.2.    Normative references

   [Needs references to RFC2119, RFC2026, the GSS-API (RFCs 2743 &
    2744), SASL, SSHv2, IKEv2, IPsec, Kerberos V, ...]

   [RFC2026]
      S. Bradner, RFC2026:  "The Internet Standard Process - Revision
      3," October 1996, Obsoletes - RFC 1602, Status: Best Current
      Practice.

   [RFC2119]
      S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
      Indicate Requirement Levels," March 1997, Status: Best Current
      Practice.

   [RFC2743]
      J. Linn, RFC2743: "Generic Security Service Application Program
      Interface Version 2, Update 1," January 2000, Status: Proposed
      Standard.

   [RFC2744]
      J. Wray, RFC2744: "Generic Security Service API Version 2 :
      C-bindings," January 2000, Status: Proposed Standard.

   [IPSP-APIREQ]
      W. Sommerfeld, draft-ietf-ipsp-ipsec-apireq-00:  "Requirements for
      an IPsec API," June 2003, Status: Draft.

N. M. and D. Noveck, "Network File System
              (NFS) version 4 Protocol", RFC 3530, April 2003.

Author's Address

   Nicolas Williams							[Page 11]

DRAFT		Channel Bindings to Secure Channels	Expires November 2004

   ...

8.    Acknowledgements
   Sun Microsystems
   5300 Riata Trace Ct
   Austin, TX  78727
   US

   EMail: Nicolas.Williams@sun.com

Appendix A.  Acknowledgments

   The author would like to thank Mike Eisler for his work on the
   Channel Conjunction Mechanism I-D and for bringing the problem to a
   head, Sam Hartman for pointing out that channel bindings provide a
   general solution to the channel binding problem, Jeff Altman for his
   suggestion of using the TLS finished messages as the TLS channel
   bindings, as well as Bill Sommerfeld, for his help in developing channel
   bindings for IPsec, and Radia Perlman for their her most helpful comments.

9.    Author's Address

   Nicolas Williams
   Sun Microsystems
   5300 Riata Trace Ct
   Austin, TX 78727
   Email: nicolas.williams@sun.com

Full Copyright

Intellectual Property Statement

   Copyright (C)

   The Internet Society (2003).  All Rights Reserved.

   This document and translations IETF takes no position regarding the validity or scope of it may any
   Intellectual Property Rights or other rights that might be copied and furnished claimed to
   others, and derivative works that comment on or otherwise explain it
   or assist in its
   pertain to the implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction use of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, technology described in
   this document itself may or the extent to which any license under such rights
   might or might not be modified in available; nor does it represent that it has
   made any independent effort to identify any way, such as by removing rights.  Information
   on the copyright notice or references procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the Internet Society IETF Secretariat and any
   assurances of licenses to be made available, or other
   Internet organizations, except as needed for the purpose result of
   developing Internet standards in which case the procedures an
   attempt made to obtain a general license or permission for
   copyrights defined in the Internet Standards process must be
   followed, use of
   such proprietary rights by implementers or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not users of this
   specification can be
   revoked by obtained from the Internet Society or IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its successors attention any
   copyrights, patents or assigns. patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein is are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

N. Williams							[Page 12]