Re: [Emu] Last call comments: draft-williams-on-channel-binding-01.txt: EAP channel bindings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Below are diffs to draft-williams-on-channel-binding-01.txt including:

 - Alexey Melnikov's IANA text
 - Fixes to Eric Gray's nits
 - New text about EAP channel binding
 - A clarification requested by Sam: this doc describes a generic notion
   of channel binding, not [just] the GSS-API's

Please review and comment.  Particularly w.r.t. EAP channel binding.


--- on-channel-binding-01.txt
+++ on-channel-binding-02.txt
@@ -1,18 +1,18 @@
 
 
 
 NETWORK WORKING GROUP                                        N. Williams
 Internet-Draft                                                       Sun
-Expires: September 6, 2007                                 March 5, 2007
+Expires: October 18, 2007                                 April 16, 2007
 
 
            On the Use of Channel Bindings to Secure Channels
-                draft-williams-on-channel-binding-01.txt
+                draft-williams-on-channel-binding-02.txt
 
 Status of this Memo
 
    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.
 
@@ -27,17 +27,17 @@
    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/ietf/1id-abstracts.txt.
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on September 6, 2007.
+   This Internet-Draft will expire on October 18, 2007.
 
 Copyright Notice
 
    Copyright (C) The IETF Trust (2007).
 
 
 
 
@@ -47,19 +47,19 @@
 
 
 
 
 
 
 
 
-Williams                Expires September 6, 2007               [Page 1]
+Williams                Expires October 18, 2007                [Page 1]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
 Abstract
 
    The concept of channel binding allows applications to establish that
    the two end-points of a secure channel at one network layer are the
    same as at a higher layer by binding authentication at the higher
    layer to the channel at the lower layer.  This allows applications to
@@ -71,59 +71,59 @@
 
 
 Table of Contents
 
    1.          Introduction . . . . . . . . . . . . . . . . . . . . .  3
    1.1.        Conventions used in this document  . . . . . . . . . .  4
    2.          Definitions  . . . . . . . . . . . . . . . . . . . . .  5
    2.1.        Properties of channel binding  . . . . . . . . . . . .  6
+   2.2.        EAP channel binding  . . . . . . . . . . . . . . . . .  8
    3.          Authentication and channel binding semantics . . . . .  9
    3.1.        The GSS-API and channel binding  . . . . . . . . . . .  9
    3.2.        SASL and channel binding . . . . . . . . . . . . . . .  9
    4.          Channel bindings specifications  . . . . . . . . . . . 11
    4.1.        Examples of unique channel bindings  . . . . . . . . . 11
    4.2.        Examples of end-point channel bindings . . . . . . . . 11
    5.          Uses of channel binding  . . . . . . . . . . . . . . . 13
    6.          Benefits of channel binding to secure channels . . . . 15
    7.          IANA Considerations  . . . . . . . . . . . . . . . . . 16
-   8.          Security Considerations  . . . . . . . . . . . . . . . 17
+   7.1.        Registration Procedure . . . . . . . . . . . . . . . . 16
+   7.2.        Comments on channel bindings Registrations . . . . . . 17
+   7.3.        Change control . . . . . . . . . . . . . . . . . . . . 18
+   8.          Security Considerations  . . . . . . . . . . . . . . . 19
    8.1.        Non-unique channel bindings and channel binding
-               re-establishment . . . . . . . . . . . . . . . . . . . 17
-   9.          References . . . . . . . . . . . . . . . . . . . . . . 19
-   9.1.        Normative References . . . . . . . . . . . . . . . . . 19
-   9.2.        Informative References . . . . . . . . . . . . . . . . 19
-   Appendix A. Acknowledgments  . . . . . . . . . . . . . . . . . . . 22
-               Author's Address . . . . . . . . . . . . . . . . . . . 23
-               Intellectual Property and Copyright Statements . . . . 24
+               re-establishment . . . . . . . . . . . . . . . . . . . 19
+   9.          References . . . . . . . . . . . . . . . . . . . . . . 21
+   9.1.        Normative References . . . . . . . . . . . . . . . . . 21
+   9.2.        Informative References . . . . . . . . . . . . . . . . 21
+   Appendix A. Acknowledgments  . . . . . . . . . . . . . . . . . . . 24
+               Author's Address . . . . . . . . . . . . . . . . . . . 25
+               Intellectual Property and Copyright Statements . . . . 26
 
 
 
 
 
 
 
 
 
 
+Williams                Expires October 18, 2007                [Page 2]
 
+Internet-Draft             On Channel Bindings                April 2007
 
 
-
-Williams                Expires September 6, 2007               [Page 2]
-
-Internet-Draft             On Channel Bindings                March 2007
-
-
 1.  Introduction
 
    In a number of situations, it is useful for an application to be able
    to handle authentication within the application layer, while
    simultaneously being able to utilize session or transport security at
-   a lower network layer.  For example, while IPsec [RFC4301] [RFC4303]
+   a lower network layer.  For example, IPsec [RFC4301] [RFC4303]
    [RFC4302] is amenable to being accelerated in hardware to handle very
    high link speeds, but IPsec key exchange protocols and the IPsec
    architecture are not as amenable to use as a security mechanism
    within applications, particularly applications that have users as
    clients.  A method of combining security at both layers is therefore
    attractive.  To enable this to be done securely, it is necessary to
    "bind" the mechanisms together -- so as to avoid man-in-the-middle
    vulnerabilities and enable the mechanisms to be integrated in a
@@ -131,49 +131,58 @@
 
    The term "channel binding" as used in this document derives from the
    GSS-API [RFC2743], which has a channel binding facility that was
    intended for binding GSS-API authentication to secure channels at
    lower network layers.  The purpose and benefits of the GSS-API
    channel binding facility were not discussed at length, and some
    details were left unspecified.  Now we find that this concept can be
    very useful, therefore we begin with a generalization and
-   formalization of "channel binding."
+   formalization of "channel binding" independent of the GSS-API.
 
+   Although inspired by and derived from the GSS-API, the notion of
+   channel binding described herein is not at all limited to use by GSS-
+   API applications.  We envision use of channel binding by applications
+   that utilize other security frameworks, such as SASL [RFC4422] and
+   even protocols that provide their own authentication mechanisms
+   (e.g., the KDC exchanges of Kerberos V [RFC4120]).  We also envision
+   use of the notion of channel binding in the analysis of security
+   protocols.
+
    The main goal of channel binding is to be able to delegate
    cryptographic session protection to network layers below the
    application in hopes of being able to better leverage hardware
    implementations of cryptographic protocols.  Section 5 describes some
    intended uses of channel binding.  Some applications may benefit
    additionally by reducing the amount of active cryptographic state,
    thus reducing overhead in accessing such state and, therefore, the
    impact of security on latency.
 
    The critical security problem to solve in order to achieve such
    delegation of session protection is: ensuring 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.
 
+
+
+
+Williams                Expires October 18, 2007                [Page 3]
+
+Internet-Draft             On Channel Bindings                April 2007
+
+
    And there may well be a MITM, particularly if the lower network layer
    either provides no authentication or if there is no strong connection
    between the authentication or principals used at the application and
    those used at the lower network layer.
 
    Even if such MITM attacks seem particularly difficult to effect, the
    attacks must be prevented for certain applications to be able to make
    effective use of technologies such as IPsec [RFC2401] [RFC4301] or
    HTTP with TLS [RFC4346] in certain contexts (e.g., when there is no
-
-
-
-Williams                Expires September 6, 2007               [Page 3]
-
-Internet-Draft             On Channel Bindings                March 2007
-
-
    authentication to speak of, or when one node's set of trust anchors
    is too weak to believe that it can authenticate its peers).
    Additionally, secure channels that are susceptible to MITM attacks
    because they provide no useful end-point authentication are useful
    when combined with application-layer authentication (otherwise they
    are only somewhat "better than nothing" -- see BTNS
    [I-D.ietf-btns-prob-and-applic]).
 
@@ -206,30 +215,21 @@
 
 
 
 
 
 
 
 
+Williams                Expires October 18, 2007                [Page 4]
 
+Internet-Draft             On Channel Bindings                April 2007
 
 
-
-
-
-
-
-
-Williams                Expires September 6, 2007               [Page 4]
-
-Internet-Draft             On Channel Bindings                March 2007
-
-
 2.  Definitions
 
    o  Secure channel: a packet, datagram, octet stream connection, or
       sequence of connections, between two end-points that affords
       cryptographic integrity and, optionally, confidentiality to data
       exchanged over it.  We assume that the channel is secure -- if an
       attacker can successfully cryptanalyze a channel's session keys,
       for example, then the channel is not secure.
@@ -261,104 +261,96 @@
             channel bindings that name the authenticated end-points, or
             even a single end-point, of a channel which are, in turn,
             securely bound to the channel, but which do not identify a
             channel uniquely in time.
 
    o  Cryptographic binding: (e.g., "cryptographically bound") a
       cryptographic operation that causes an object, such as a private
       encryption or signing key, or an established secure channel, to
-      "speak for" [Lapmson91] some principal, such as a user, a
+      "speak for" [Lampson91] some principal, such as a user, a
       computer, etcetera.  For example, a PKIX certificate binds a
       private key to the name of a principal in the trust domain of the
       certificate's issuer such that a possessor of said private key can
       act on behalf of the user (or other entity) named by the
       certificate.
 
 
 
 
-Williams                Expires September 6, 2007               [Page 5]
+Williams                Expires October 18, 2007                [Page 5]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
-      Cryptographic bindings are generally assymetric in nature (not to
+      Cryptographic bindings are generally asymmetric in nature (not to
       be confused with symmetric or assymetric key cryptography) in that
       an object is rendered capable of standing for another, but the
       reverse is not usually the case (we don't say that a user speaks
       for their private keys, but we do say that the user's private keys
       speak for the user).
 
    Note that there may be many instances of "cryptographic binding" in
    an application of channel binding.  The credentials that authenticate
    principals at the application layer bind private or secret keys to
    the identities of those principals, such that said keys speak for
    them.  A secure channel typically consists symmetric session keys
-   used to provide confidentiality and integrity ptoection to data sent
+   used to provide confidentiality and integrity protection to data sent
    over the channel; each end-point's session keys speak for that end-
    point of the channel.  Finally, each end-point of a channel bound to
    authentication at the application layer speaks for the principal
    authenticated at the application layer on the same side of the
    channel.
 
    The terms defined above have been in use for many years and have been
    taken to mean, at least in some contexts, what is stated below.
    Unfortunately this means that "channel binding" can refer to the
    channel binding operation and, sometimes to the name of a channel,
    and "channel bindings" -- a difference of only one letter --
    generally refers to the name of a channel.
 
-   Also unfortunately there is a conflict with the Extensible
-   Authentication Protocol (EAP) [RFC3748] which uses "channel binding"
-   to refer to a facility that is subtly different from the one
-   described here.  (It does not seem feasible to adopt new terminology
-   to avoid these problems now.  The GSS-API, NFSv4 and other
-   communities have been using the terms "channel binding" and "channel
-   bindings" in these ways for a long time, sometimes with variations
-   such as "channel binding facility" and so on.)
+   Note that the Extensible Authentication Protocol (EAP) [RFC3748]
+   which "channel binding" to refer to a facility that is substantially
+   similar one described here.  See Section 2.2 for more details.
 
 2.1.  Properties of channel binding
 
-   [NOTE: This section needs more work, I'm sure I've missed
-   somethings...]
-
    Applications, authentication frameworks (e.g., the GSS-API, SASL),
    security mechanisms (e.g., the Kerberos V GSS-API mechanism
    [RFC1964]) and secure channels must meet the following requirement
    and should follow the following recommendations.
 
    Requirements:
 
+   o  Specifications of channel bindings for any secure channels MUST
+      provide for a single, canonical octet string encoding of the
+      channel bindings.
 
+   o  The channel bindings for a given type of secure channel MUST be
+      constructed in such a way that an MITM could not easily force the
+      channel bindings of a given channel to match those of another.
 
 
 
-Williams                Expires September 6, 2007               [Page 6]
 
-Internet-Draft             On Channel Bindings                March 2007
 
+Williams                Expires October 18, 2007                [Page 6]
 
-   o  Specifications of channel bindings for any secure channels MUST
-      provide for a single, canonical octet string encoding of the
-      channel bindings.
+Internet-Draft             On Channel Bindings                April 2007
 
-   o  The channel bindings for a given type of secure channel MUST be
-      constructed in such a way that an MITM could not easily force the
-      channel bindings of a given channel to match those of another.
 
    o  Unique channel bindings MUST bind not only the key exchange for
       the secure channel, but also any negotiations and authentication
       that may have taken place to establish the channel.
 
    o  End-point channel bindings MUST be bound into the secure channel
       and all its negotiations.  E.g., if an end-point channel binding
       is the name of a certificate and this certificate is used in
-      establishng the channel to sign material, say, all the initinial
-      key exchange and negotiation messages for that channel, then that
+      establishng the channel to sign material, say, all the initial key
+      exchange and negotiation messages for that channel, then that
       certificate name could be said to be bound into the channel.
 
    o  End-point channel bindings may be identifiers which must be
       authenticated through some infrastructure, such as a public key
       infrastructure (PKI).  In such cases the channel binding can be no
       stronger, cryptographically, than the infrastructure, including
       trust establishment.  Applications MUST NOT use end-point channel
       bindings when the end-points cannot be strongly authenticated due
@@ -365,47 +357,47 @@
       to the configuration of the authentication service (e.g., because
       there are too many trust anchors, or because some are of dubious
       repute).
 
    o  Applications MUST use application-layer session protection
       services for confidentiality protection when the bound channel
       does not provide confidentiality protection.
 
-   o  The integrity of a secure channels MUST NOT be weakened should
+   o  The integrity of a secure channel MUST NOT be weakened should
       their channel bindings be revealed to an attacker.  That is, the
       construction of the channel bindings for any type of secure
       channel MUST NOT leak secret information about the channel.  End-
       point channel bindings, however, MAY leak information about the
       end-points of the channel (e.g., their names).
 
    o  The channel binding operation MUST be at least integrity protected
       in the security mechanism used at the application layer.
 
    o  Authentication frameworks and mechanisms that support channel
       binding MUST communicate channel binding failure to applications.
 
    Recommendations:
 
-
-
-
-Williams                Expires September 6, 2007               [Page 7]
-
-Internet-Draft             On Channel Bindings                March 2007
-
-
    o  Applications SHOULD use mutual authentication at the application
       layer when using channel binding.
 
    o  End-point channel bindings where the end-points are meaningful
       names SHOULD NOT be used when the channel does not provide
       confidentiality protection and privacy protection is desired.
       Alternatively channels that export such channel bindings SHOULD
       provide for the use of a digest and SHOULD NOT introduce new
+
+
+
+Williams                Expires October 18, 2007                [Page 7]
+
+Internet-Draft             On Channel Bindings                April 2007
+
+
       digest/hash agility problems as a result.
 
    Options:
 
    o  Authentication frameworks and mechanisms that support channel
       binding MAY fail to establish authentication if channel binding
       fails.
 
@@ -415,45 +407,53 @@
    o  A security mechanism MAY exchange integrity protected digests of
       channel bindings.  Such mechanisms SHOULD provide for hash/digest
       agility.
 
    o  A security mechanism MAY use channel bindings in key exchange,
       authentication or key derivation, prior to the exchange of
       "authenticator" messages.
 
+2.2.  EAP channel binding
 
+   This section is informative.  This document does not update EAP
+   [RFC3748], it imposes no requirements on EAP nor EAP methods.
 
+   EAP [RFC3748] includes a concept of channel binding desribed as
+   follows:
 
+      The communication within an EAP method of integrity-protected
+      channel properties such as endpoint identifiers which can be
+      compared to values communicated via out of band mechanisms (such
+      as via a AAA or lower layer protocol).
 
+   Section 7.15 of [RFC3748] describes the problem as one where an
+   attacker may impersonate a Network Access Server (NAS), (a.k.a.
+   "authenticator").  Although not stated clearly therein, this leads to
+   an MITM attack on the EAP peer whereby one NAS pretends to be the one
+   that the peer wanted to connect to; the attacker then passes all
+   communications through to the real NAS and ultimately it will be an
+   MITM between the peer and the real NAS.
 
+   Section 7.15 of [RFC3748] calls for "a protected exchange of channel
+   properties such as endpoint identifiers" such that "it is possible to
+   match the channel properties provided by the authenticator via out-
+   of-band mechanisms against those exchanged within the EAP method."
+   In other words: EAP channel binding is very similar to the generic
+   notion of channel binding described in this document, both in terms
+   of intent and in terms of how it is intended to operate.
 
 
 
 
+Williams                Expires October 18, 2007                [Page 8]
 
+Internet-Draft             On Channel Bindings                April 2007
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-Williams                Expires September 6, 2007               [Page 8]
-
-Internet-Draft             On Channel Bindings                March 2007
-
-
 3.  Authentication and channel binding semantics
 
    Some authentication frameworks and/or mechanisms provide for channel
    binding, such as the GSS-API and some GSS-API mechanisms, whereas
    others may not, such as SASL (however, ongoing work is adding channel
    binding support to SASL).  Semantics may vary with respect to
    negotiation, how the binding occurs, and handling of channel binding
    failure (see below).
@@ -495,19 +495,19 @@
    Work is ongoing [I-D.ietf-sasl-gs2] to specify how SASL, particularly
    it's new bridge to the GSS-API, performs channel binding.  SASL will
    likely differ from the GSS-API in its handling of channel binding
    failure (i.e., when there may be a MITM) in that channel binding
    success/failure will only affect the negotiation of SASL security
 
 
 
-Williams                Expires September 6, 2007               [Page 9]
+Williams                Expires October 18, 2007                [Page 9]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
    layers.  I.e., when channel binding succeeds SASL should select no
    security layers, leaving session cryptographic protection to the
    secure channel that has been bound to.
 
 
 
@@ -551,19 +551,19 @@
 
 
 
 
 
 
 
 
-Williams                Expires September 6, 2007              [Page 10]
+Williams                Expires October 18, 2007               [Page 10]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
 4.  Channel bindings specifications
 
    Channel bindings for various types of secure channels are not
    described herein.  Some channel bindings specifications can be found
    in:
 
@@ -570,19 +570,21 @@
    +--------------------+----------------------------------------------+
    | Secure Channel     | Reference                                    |
    | Type               |                                              |
    +--------------------+----------------------------------------------+
    | SSHv2              | [I-D.williams-sshv2-channel-bindings]        |
    |                    |                                              |
    | TLS                | [I-D.altman-tls-channel-bindings]            |
    |                    |                                              |
-   | IPsec              | There is no specification for this yet. We   |
-   |                    | expect that channel bindings for IPsec will  |
-   |                    | be of the non-unique variety.                |
+   | IPsec              | There is no specification for IPsec channel  |
+   |                    | bindings yet, but the IETF Better Than       |
+   |                    | Nothing Security (BTNS) WG is working to     |
+   |                    | specify IPsec channels, and possibly IPsec   |
+   |                    | channel bindings.                            |
    +--------------------+----------------------------------------------+
 
 4.1.  Examples of unique channel bindings
 
    The following text is not normative, but is here to show how one
    might construct channel bindings for various types of secure
    channels.
 
@@ -602,26 +604,26 @@
    The following text is not normative, but is here to show how one
    might construct channel bindings for various types of secure
    channels.
 
    For SSHv2 [RFC4251] the SSHv2 host public key, when present, should
    suffice as it is used to sign the algorithm suite negotiation and
    Diffie-Hellman key exchange; as long the client observes the host
    public key that corresponds to the private host key that the server
-   used then there cannot be a MITM in the SSHv2 connection.  Note that
-   not all SSHv2 key exchanges use host public keys, therefore this
 
 
 
-Williams                Expires September 6, 2007              [Page 11]
+Williams                Expires October 18, 2007               [Page 11]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
+   used then there cannot be a MITM in the SSHv2 connection.  Note that
+   not all SSHv2 key exchanges use host public keys, therefore this
    channel bindings construction is not as useful as the one given in
    Section 4.1 above.
 
    For TLS [RFC4346]the server certificate should suffice for the same
    reasons as above.  Again, not all TLS cipher suites involve server
    certificates, therfore the utility of this construction of channel
    bindings is limited to scenarios where server certificates are
    commonly used.
@@ -661,23 +663,21 @@
 
 
 
 
 
 
 
 
+Williams                Expires October 18, 2007               [Page 12]
 
+Internet-Draft             On Channel Bindings                April 2007
 
-Williams                Expires September 6, 2007              [Page 12]
 
-Internet-Draft             On Channel Bindings                March 2007
-
-
 5.  Uses of channel binding
 
    Uses for channel binding identified so far:
 
    o  Delegating session cryptographic protection to layers where
       hardware can reasonably be expected to support relevant
       cryptographic protocols:
 
@@ -719,30 +719,30 @@
    cleartext relative to this RDDP layer, or the RDDP implementation
    must know how to implement cryptographic session protection protocols
    used at the application layer.
 
    There are a multitude of application layer cryptographic session
 
 
 
-Williams                Expires September 6, 2007              [Page 13]
+Williams                Expires October 18, 2007               [Page 13]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
    protection protocols available.  It is not reasonable to expect the
    NICs should support many such protocols.  Further, some application
    protocols may maintain many cryptographic session contexts per-
    connection (for example, NFSv4 does).  It is thought to be simpler to
-   push the cryptographic session protection down the network stack, to
-   IPsec, and yet be able to produce NICs that offload TCP/IP, ESP/AH,
-   and DDP operations, than it would be to add support in the NIC for
-   the many session cryptographic protection protocols in use in common
-   applications at the application layer.
+   push the cryptographic session protection down the network stack (to
+   IPsec), and yet be able to produce NICs that offload other operations
+   (i.e. - TCP/IP, ESP/AH, and DDP), than it would be to add support in
+   the NIC for the many session cryptographic protection protocols in
+   use in common applications at the application layer.
 
    The following figure shows how the various network layers are
    related:
 
       +---------------------+
       | Application layer   |<---+
       |                     |<-+ |  In cleartext, relative
       +---------------------+  | |  to each other.
@@ -775,19 +775,19 @@
 
 
 
 
 
 
 
 
-Williams                Expires September 6, 2007              [Page 14]
+Williams                Expires October 18, 2007               [Page 14]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
 6.  Benefits of channel binding to secure channels
 
    The use of channel binding to delegate session cryptographic
    protection include:
 
    o  Performance improvements by avoiding double protection of
@@ -831,77 +831,189 @@
 
 
 
 
 
 
 
 
-Williams                Expires September 6, 2007              [Page 15]
+Williams                Expires October 18, 2007               [Page 15]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
 7.  IANA Considerations
 
-   There are no IANA considerations in this document.
+   The IANA is hereby requested to create a new registry for channel
+   bindings specifciations for various types of channels.
 
+   The purpose of this registry is not only to ensure uniqueness of
+   values used to name channel bindings, but also to provide a
+   definitive reference to technical specifications detailing each
+   channel binding available for use on the Internet.
 
+   There is no naming convention for channel bindings: any string
+   composed of US-ASCII alphanumeric characters, period ('.') and dash
+   ('-') will suffice.
 
+   The procedure detailed in Section 7.1 is to be used for registration
+   of a value naming a specific individual mechanism.
 
+   Comments may be included in the registry as discussed in Section 7.2
+   and may be changed as discussed in Section 7.3.
 
+7.1.  Registration Procedure
 
+   Registration of a new channel binding requires expert review as
+   defined in BCP 26 [RFC2434].
 
+   Registration of a Channel binding is requested by filling in the
+   following template:
 
+   o  Subject: Registration of channel binding X
 
+   o  Channel binding unique prefix (name):
 
+   o  Channel binding type: (One of "unique" or "end-point")
 
+   o  Channel type: (E.g., TLS, IPsec, SSH, etc...)
 
+   o  Published specification (recommended, optional):
 
+   o  Description (optional if a specification is given; required if no
+      Published specification is specified):
 
+   o  Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE)
 
+   o  Person and email address to contact for further information:
 
+   o  Owner/Change controller name and email address:
 
 
 
 
 
+Williams                Expires October 18, 2007               [Page 16]
 
+Internet-Draft             On Channel Bindings                April 2007
 
 
+   o  Expert reviewer name and contact information: (leave blank)
 
+   o  Note: (Any other information that the author deems relevant may be
+      added here.)
 
+   and sending it via electronic mail to a list to be determined [note:
+   an ietf.org list for this is needed, say, channel-binding@xxxxxxxx]
+   and carbon copying IANA at <iana@xxxxxxxx>.  After allowing two weeks
+   for community input on the mailing list to be determined, an expert
+   will determine the appropriateness of the registration request and
+   either approve or disapprove the request with notice to the
+   requestor, the mailing list, and IANA.
 
+   If the expert approves registration, it adds her/his name to the
+   submitted registration.
 
+   The expert has the primary responsibility of making sure that channel
+   bindings for IETF specifications go through the IETF consensus
+   process and that prefixes are unique.
 
+   The review should focus on the appropriateness of the requested
+   channel binding for the proposed use, the appropriateness of the
+   proposed prefix and correctness of the channel binding type in the
+   registration.  The scope of this request review may entail
+   consideration of relevant aspects of any provided technical
+   specification, such as their IANA Considerations section.  However,
+   this review is narrowly focused on the appropriateness of the
+   requested registration and not on the overall soundness of any
+   provided technical specification.
 
+   Authors are encouraged to pursue community review by posting the
+   technical specification as an Internet-Draft and soliciting comment
+   by posting to appropriate IETF mailing lists.
 
+7.2.  Comments on channel bindings Registrations
 
+   Comments on a registered Channel bindings should first be sent to the
+   "owner" of the channel bindings and to the channel binding mailing
+   list.
 
+   Submitters of comments may, after a reasonable attempt to contact the
+   owner, request IANA to attach their comment to the channel binding
+   type registration itself by sending mail to <iana@xxxxxxxx>.  At
+   IANA's sole discretion, IANA may attach the comment to the Channel
+   binding's registration.
 
 
 
 
 
 
+Williams                Expires October 18, 2007               [Page 17]
 
+Internet-Draft             On Channel Bindings                April 2007
 
 
+7.3.  Change control
 
+   Once a Channel bindings registration has been published by IANA, the
+   author may request a change to its definition.  The change request
+   follows the same procedure as the registration request.
 
+   The owner of a Channel bindings may pass responsibility for the
+   Channel bindings to another person or agency by informing IANA; this
+   can be done without discussion or review.
 
+   The IESG may reassign responsibility for a Channel bindings.  The
+   most common case of this will be to enable changes to be made to
+   mechanisms where the author of the registration has died, has moved
+   out of contact, or is otherwise unable to make changes that are
+   important to the community.
 
+   Channel bindings registrations may not be deleted; mechanisms that
+   are no longer believed appropriate for use can be declared OBSOLETE
+   by a change to their "intended usage" field; such Channel bindings
+   will be clearly marked in the lists published by IANA.
 
+   The IESG is considered to be the owner of all channel bindings that
+   are on the IETF standards track.
 
-Williams                Expires September 6, 2007              [Page 16]
 
-Internet-Draft             On Channel Bindings                March 2007
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Williams                Expires October 18, 2007               [Page 18]
+
+Internet-Draft             On Channel Bindings                April 2007
+
+
 8.  Security Considerations
 
    Security considerations appear throughout this document.  In
    particular see Section 2.1.
 
    When delegating session protection from one layer to another, one
    will almost certainly be making some session security trade-offs,
    such as using weaker cipher modes in one layer than might be used in
@@ -939,29 +1051,29 @@
 
    Consider a user multiplexing protocol like NFSv4 using channel
    binding to IPsec on a multi-user client.  If another user can connect
    directly to port 2049 (NFS) on some server using IPsec and merely
    assert RPCSEC_GSS credential handles, then this user will be able to
    impersonate any user authenticated by the client to the server.  This
    is because the new connection will have the same channel bindings as
    the NFS client's!  To prevent this the server must require that at
-   least a hostbased client principal, and perhaps all the client's user
+   least a host-based client principal, and perhaps all the client's
 
 
 
-Williams                Expires September 6, 2007              [Page 17]
+Williams                Expires October 18, 2007               [Page 19]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
-   principals, re-authenticate and perform channel binding before the
-   server will allow the clients to assert RPCSEC_GSS context handles.
-   Alternatively the protocol could: a) require that secure channels
-   provide confidentiality protection, and b) that fast re-
+   user principals, re-authenticate and perform channel binding before
+   the server will allow the clients to assert RPCSEC_GSS context
+   handles.  Alternatively the protocol could: a) require that secure
+   channels provide confidentiality protection, and b) that fast re-
    authentication cookies be difficult to guess (e.g., large numbers
    selected randomly).
 
    In other contexts there may not be such problems, for example, in the
    case of application protocols that don't multiplex users over a
    single channel and where confidentiality protection is always used in
    the secure channel.
 
@@ -999,19 +1111,19 @@
 
 
 
 
 
 
 
 
-Williams                Expires September 6, 2007              [Page 18]
+Williams                Expires October 18, 2007               [Page 20]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
 9.  References
 
 9.1.  Normative References
 
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
@@ -1055,32 +1167,32 @@
 
    [I-D.ietf-nfsv4-nfsdirect]
               Callaghan, B. and T. Talpey, "NFS Direct Data Placement",
               draft-ietf-nfsv4-nfsdirect-04 (work in progress),
               October 2006.
 
 
 
-Williams                Expires September 6, 2007              [Page 19]
+Williams                Expires October 18, 2007               [Page 21]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
    [I-D.ietf-sasl-gs2]
               Josefsson, S., "Using GSS-API Mechanisms in SASL: The GS2
               Mechanism Family", draft-ietf-sasl-gs2-06 (work in
               progress), February 2007.
 
    [I-D.williams-sshv2-channel-bindings]
               Williams, N., "Channel Bindings for Secure Shell
               Channels", draft-williams-sshv2-channel-bindings-00 (work
               in progress), July 2006.
 
-   [Lapmson91]
+   [Lampson91]
               Lampson, B., Abadi, M., Burrows, M., and E. Wobber,
               "Authentication in Distributed Systems: Theory and
               Practive", October 1991.
 
    [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
               RFC 1964, June 1996.
 
    [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
@@ -1111,19 +1223,19 @@
 
    [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
               Protocol Architecture", RFC 4251, January 2006.
 
    [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
 
 
 
-Williams                Expires September 6, 2007              [Page 20]
+Williams                Expires October 18, 2007               [Page 22]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
               Internet Protocol", RFC 4301, December 2005.
 
    [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
               December 2005.
 
    [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
@@ -1167,19 +1279,19 @@
 
 
 
 
 
 
 
 
-Williams                Expires September 6, 2007              [Page 21]
+Williams                Expires October 18, 2007               [Page 23]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
 Appendix A.  Acknowledgments
 
    Thanks to 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 binding provide a general solution to the
    channel binding problem, Jeff Altman for his suggestion of using the
@@ -1223,19 +1335,19 @@
 
 
 
 
 
 
 
 
-Williams                Expires September 6, 2007              [Page 22]
+Williams                Expires October 18, 2007               [Page 24]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
 Author's Address
 
    Nicolas Williams
    Sun Microsystems
    5300 Riata Trace Ct
    Austin, TX  78727
@@ -1279,19 +1391,19 @@
 
 
 
 
 
 
 
 
-Williams                Expires September 6, 2007              [Page 23]
+Williams                Expires October 18, 2007               [Page 25]
 
-Internet-Draft             On Channel Bindings                March 2007
+Internet-Draft             On Channel Bindings                April 2007
 
 
 Full Copyright Statement
 
    Copyright (C) The IETF Trust (2007).
 
    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
@@ -1335,10 +1447,10 @@
 
    Funding for the RFC Editor function is provided by the IETF
    Administrative Support Activity (IASA).
 
 
 
 
 
-Williams                Expires September 6, 2007              [Page 24]
+Williams                Expires October 18, 2007               [Page 26]
 


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]