Subject: Last Call: draft-williams-on-channel-binding

From: Martin Rex <[email-masked]>
Date: Wed, 14 Mar 2007 21:08:36 +0100 (MET)

I know it is in IETF last call (not WG last call) and I'm pretty late
(as always).

Section 2 Definitions
  o  Cryptographic bindings (bottom of page 5)

                                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.

A PKIX certificate binds a >>public key<< to the name of a principal,
NOT a private key.  The public key acts as a verifier for a cryptographic
proof-of-possession of a corresponding private key.
(And in the traditional PKI, there is no "act on behalf of" (=delegation),
the assumption is always always that he who can provide a proof that can
be verified with the public key it is the one and only rightful owner
asserted by the certificate.)

      (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).

The private key is NEVER involved in anything the verifier does.

The assumptions surrounding the key pair and private key include
  - the keypair was correctly created
  - the private key is sufficiently protected from compromise
  - the owner doesn't compromise/publish the private key on purpose
  - the keypair is sufficiently strong (long) against brute force attacks
  - the underlying cryptoalgorithm is sufficiently strong
  - the registration process is sufficiently reliable to assure
    that one can not easily get a certificate issued in someone
    elses name
  - the involved CAs in a trust hierarchy can not be corrupted to
    issue certs in someone elses name

If the proof-of-possession of a particular protocol involves signing
a challenge(data), then each protocol must ensure that NO other usage of
a given keypair in any other protocol or scenario will ever
request a signature on the same challenge(data).  Otherwise a replay
(attack) might be possible that does not require possession of
the private key.

Is the document intended to go to RFC with exactly this annotation:  ?

  2.1.  Properties of channel binding

     [NOTE: This section needs more work, I'm sure I've missed
     somethings...]

  3.1.  The GSS-API and channel binding

   The GSS-API [RFC2743] provides for the use of channel binding during
   initialization of GSS-API security contexts, though GSS-API
   mechanisms are not required to support this facility.
 
Authentication-only GSS-API mechanisms will usually be unable to support
channel bindings (due to lack of integrity protection facilities).

4.1.  Examples of unique channel bindings

   For TLS [RFC4346]the TLS session ID is not sufficient as it is
   assigned by the server, and so could be assigned by an MITM to match
   a server's.  Instead the initial, unencrypted TLS finished messages,
   either the client's, the server's or both, are sufficient as they are
   the output of the TLS PRF, keyed with the session key, applied to all
   handshake material.

This applies ONLY for end-to-end TLS scenarios.  If there are
several consecutive TLS tunnels between the client app and the
server app, TLS channel bindings may be entirely impossible,
e.g. when the "backend/server" uses TLS-protected channels
between backend components to forward or load-balance requests
within a backend landscape/farm (SSL-Accellerators, reverse-proxies)
that is otherwise transparent for the client.

Also keep in mind that authentication is not really used in common
HTTPS-scenarios.  There is some fairly weak "endpoint identification".
I really appreciated the terminology used by EKR in rfc2818,
not a single occurance of the word "authentication" (because
there is none in HTTPS without client certificates).

There is a serious trust gap between the "users intent" and
the typo-prone guesstimate of what a user entered into a
browsers address bar, or between the "users intent" and the
(camouflaged) hostname in an URL of a phishing Email or
phishing Website.

  8. Security Considerations

   Channel bindings should be constructed in such a way that revealing
   the channel bindings of a channel to third parties does not weaken
   the security of the channel.  However, for end-point channel bindings
   disclosure of the channel bindings may disclose the identities of the
   peers.

In 4.1. it says:

   Instead the initial, unencrypted TLS finished messages,
   either the client's, the server's or both, are sufficient as they are
   the output of the TLS PRF, keyed with the session key, applied to all
   handshake material.

So the general message is that whatever you use for channel bindings
may leak.  With this premise I would really suggest that a recommendation
be added:  whenever previously secret information is made part of
channel bindings, it should be used in a cryptographically irreversible
fashion (hash/mac) and not directly.

Cleartext finished messages of a TLS handshake have not normally been
available.  Although *I* can not directly think of an immediate
threat when they become "available" to observers/attackers,
I would recommend against it.

  Appendix A.

                                                       Sam Hartman for
   pointing out that channel binding provide a general solution to the
   channel binding problem,

Hmmmm.  I haven't yet figured out what this means.

-Martin

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten