Subject: [Unbearable] comments on -tokbind-protocol-05 aka TBPROTO

From: =JeffH <[email-masked]>
Date: Wed, 30 Mar 2016 20:59:09 -0700

review comments on -tokbind-protocol-05 aka TBPROTO:

Substantive comments:

S1. need to migrate the referred_token_binding type and its IANA
registration over to -tokbind-https aka HTTPSTB. see..

   Re: [Unbearable] -tokbind-protocol-04: verifying signature(s)
   in TokenBindingMessage.TokenBinding?
<https://www.ietf.org/mail-archive/web/unbearable/current/msg00470.html>

As part of this, we may want to explicitly state that defining the
semantics of TokenBindingMessages containing more than one provided
TokenBinding, as well as allocating new TokenBindingType value(s), is left
to applications.

S2. TBPROTO focuses on the server side binding TBIDs to "security tokens".
However, there are occasions in some protocols/apps where the client side
is obliged to bind objects to the TLS layer. See for example
<http://w3c.github.io/webauthn/#sec-client-data>. TBPROTO should more
clearly explain that either the client or server side may bind TBIDs into
objects (tokens, messages, whatever) and either side may be obliged to
validate such objects, depending on application use case(s).

S3. It seems that TBPROTO intends to be a general purpose app-layer means
for generating and agreeing on TBIDs, i.e., it is not just for HTTP; it
seems to serve the purpose of mitigating the need for different app-layers
to re-invent such a mechanism on their own. In doing so, it arguably is
acting as general-purpose packaging of the TLS keying material exporter,
and insulating other app-layer designers from the vagaries described in
the last parag of the sec cons in RFC5705..

   Designing a secure mechanism that uses exporters is not necessarily
   straightforward. This document only provides the exporter mechanism,
   but the problem of agreeing on the surrounding context and the
   meaning of the information passed to and from the exporter remains.
   Any new uses of the exporter mechanism should be subject to careful
   review.

If so, this should be stated more explicitly in TBPROTO.

S5. Should TBPROTO have a "Required Application Programming Interfaces"
section similar to that in RFC5929 [1] ?

S6a. How TBIDs are "reset" is not described. Presumably, this is
accomplished by the client allocating a new key pair for a server,
resigning EKM, and including the new values in the "next"
TokenBindingMessage sent to the server, and servers need to be vigilant
about noticing new TBIDs and re-binding application security
tokens/messages as appropriate, yes?

S6b. Our Security AD verbally expressed to some of us (at IETF-94?) that
simply saying "TBIDs can be reset by the user at any time" is insufficient
guidance to app-layer designers regarding a privacy-preserving utilization
of TBPROTO. What else might be added? Perhaps suggestion(s) that the
app-layer periodically auto-reset TBIDs?

S7. Section 6 Security Token Validation specifies conditions (eg incorrect
TBID) upon which the server "MUST discard the token". Are there not a
range of application behaviors that might occur, e.g., terminating the
application session? Or, is this particular behavior defined in order to
accommodate resetting of TBIDs by the client-side whereupon there may be a
race condition before all the server-issued bound app sec tokens contain
the updated TBID? Is this behavior appropriate for all apps in all cases?
what if an incorrect bound TBID is being caused by a MITM?

S8. Section 8.2 Security Token Replay is fairly light on details regarding
how an application layer can utilize TBPROTO to detect MITM attacks,
perhaps appropriately generalizing and including the 2nd parag from [2]
would help readers better understand how this would work?

S9. I would not say "TLS Token Binding IDs are never transmitted in clear
text.." -- this could easily occur in an HTTP-based web app that
inadvertently leaks cookies, e.g. by retrieving some image over plain
http. addressing this implies adding sec cons wrt such risks, eg "apps
need to take precautions to ensure bound sec tokens/messages are not
'leaked' over insecure connections such as can occur due to non-https
link(s) lurking in a web app, e.g., an image load. HTTP-based applications
should employ techniques such as HSTS and HPKP in order to guard against
such situations."

S10. I would remove the triple-handshake admonition in section 4, and
perhaps the one in sec cons, but in any case add to sec cons that there
are important sec cons regarding the underlying TLS connection in
[I-D.ietf-tokbind-negotiation] that could mitigate the app-layer's
TB-based security benefits if they are not heeded.

S11. Regarding the design decision: TokenBindingType is not within
TokenBindingID -- it is within the enclosing TokenBinding because
TokenBindingIDs (TBIDs) may be conveyed in TBMSG as either provided_ or
some other app-layer-defined TBType. If the app-layer has defined
additional TBType(s), the server-side would want to remember each TBID's
type, yes?

S12. Perhaps spec should stipulate "server must ignore TBTypes it does not
understand" -- or not?

[1] https://tools.ietf.org/html/rfc5929#section-7

[2] <https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-4.4>

Overall editorial issues/comments (in no particular order):

E1. the mechanics of verifying the signature(s) in a TokenBindingMessage
are not spec'd in detail -- experienced crypto folk may know what to do,
but others may not.

E2. ought to clearly delineate "server processing model" and "client
processing model". (e.g. see https://tools.ietf.org/html/rfc6797)

E3. section "1. Introduction" and section "2. token binding protocol
overview" are quite similar -- perhaps they could be combined?

E4. If section 3 and 4 are massaged per E2, section 5 becomes superfluous
(it seemed to in my experimenting).

E4. the security considerations section contains RFC2119 requirements
language -- some downstream reviews may frown on this.

E5. TBPROTO in and of itself does not "prevent" export and replay of app
security tokens -- rather it facilitates detection of such occurances.

E6. Terminology is fairly loose, e.g. terms such as "token", "security
token", "bound token", "bound security token" are not used as consistently
as they could be.

E7. Various spec portions could benefit from further wordsmithing --
suggestions are inline below...

<snip>
 >                  The Token Binding Protocol Version 1.0
 >                      draft-ietf-tokbind-protocol-05
 >
<snip>
 >
 > 1.  Introduction
 >
 >    Servers generate various security tokens (e.g.  HTTP cookies, OAuth
 >    tokens) for applications to access protected resources.  Any party in
 >    possession of such token gains access to the protected resource.
 >    Attackers export bearer tokens from the user's machine, present them
 >    to the servers, and impersonate authenticated users.  The idea of
 >    Token Binding is to prevent such attacks by cryptographically binding
 >    security tokens to the TLS layer.
 >
 >    A TLS Token Binding is established by the user agent generating a

s/the user agent/a client-side application (e.g., a user agent)/

 >    private-public key pair (possibly within a secure hardware module,
 >    such as TPM) per target server, and proving possession of the private
 >    key on every TLS connection to the target server.  The proof of
 >    possession involves signing the exported keying material [RFC5705]
 >    for the TLS connection with the private key.  The corresponding
 >    public key is included in the TLS Token Binding identifier structure
 >    (described in the "TLS Token Binding ID Format" section of this
 >    document).  TLS Token Bindings are long-lived, i.e. they encompass
 >    multiple TLS connections and TLS sessions between a given client and
 >    server.  To protect privacy, TLS Token Binding IDs are never
 >    transmitted in clear text and can be reset by the user at any time,
 >    e.g. when clearing browser cookies.
 >
 >    When issuing a security token to a client that supports TLS Token
 >    Binding, a server includes the client's TLS Token Binding ID in the
 >    token.  Later on, when a client presents a security token containing
 >    a TLS Token Binding ID, the server makes sure the ID in the token
 >    matches the ID of the TLS Token Binding established with the client.
 >    In the case of a mismatch, the server discards the token.
 >
 >    In order to successfully export and replay a bound security token,
 >    the attacker needs to also be able to export the client's private
 >    key, which is hard to do in the case of the key generated in a secure
 >    hardware module.
 >
 > 1.1.  Requirements Language
 >
 >    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].
 >
 > 2.  Token Binding Protocol Overview

this section largely duplicates the Introduction -- could the intro be
trimmed way down and then this section effectively provides the underlying
details that are summarized in the Intro?

 >
 >    The client and server use the Token Binding Negotiation TLS Extension
 >    [I-D.ietf-tokbind-negotiation] to negotiate the Token Binding
 >    protocol version and the parameters (signature algorithm, length) of
 >    the Token Binding key.  This negotiation does not require additional
 >    round-trips.

wrt "the parameters (signature algorithm, length)" -- this is now
effectively referred to as "key parameters" yes?

 >    The Token Binding protocol consists of one message sent by the client
 >    to the server, proving possession of one or more client-generated
 >    asymmetric keys.  This message is only sent if the client and server
 >    agree on the use of the Token Binding protocol and the key
 >    parameters.  The Token Binding message is sent with the application
 >    protocol data in TLS application_data records.

wrt... "The Token Binding message is sent with the application
protocol data in TLS application_data records"

...in other words, after Token Binding negotiation during TLS handshake
[I-D.ietf-tokbind-negotiation], the Token Binding msg is created by the
client and conveyed to the server in the app layer protocol which is
running over TLS within whose context the token binding ID was
established. Yes?

perhaps re-state.

 >    A server receiving the Token Binding message verifies that the key
 >    parameters in the message match the Token Binding parameters
 >    negotiated via [I-D.ietf-tokbind-negotiation], and then validates the
 >    signatures contained in the Token Binding message.  If either of
 >    these checks fails, the server terminates the connection, otherwise
 >    the TLS Token Binding is successfully established with the ID
 >    contained in the Token Binding message.
 >
 >    When a server supporting the Token Binding protocol receives a bound
 >    token, the server compares the TLS Token Binding ID in the security
 >    token with the TLS Token Binding ID established with the client.  If
 >    the bound token came from a TLS connection without a Token Binding,
 >    or if the IDs don't match, the token is discarded.
 >
 >    This document defines the format of the Token Binding protocol
 >    message, the process of establishing a TLS Token Binding, the format
 >    of the Token Binding ID, and the process of validating a security
 >    token.

s/security token/bound security token/

 >            Token Binding Negotiation TLS Extension
 >    [I-D.ietf-tokbind-negotiation] describes the negotiation of the Token
 >    Binding protocol and key parameters.  Token Binding over HTTP
 >    [I-D.ietf-tokbind-https] explains how the Token Binding message is
 >    encapsulated within HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] messages.
 >    [I-D.ietf-tokbind-https] also describes Token Binding between
 >    multiple communicating parties: User Agent, Identity Provider and
 >    Relying Party.
 >
 > 3.  Token Binding Protocol Message
 >
 >    The Token Binding message is sent by the client and proves possession
 >    of one or more private keys held by the client.  This message MUST be
 >    sent if the client and server successfully negotiated the use of the
 >    Token Binding protocol via [I-D.ietf-tokbind-negotiation], and MUST
 >    NOT be sent otherwise.  This message MUST be sent in the client's
 >    first application protocol message.  This message MAY also be sent in
 >    subsequent application protocol messages, proving possession of other
 >    keys by the same client, to facilitate token binding between more
 >    than two communicating parties.

suggest beginning new parag here..

 >                                       Token Binding over HTTP
 >    [I-D.ietf-tokbind-https] specifies the encapsulation of the Token
 >    Binding message in the application protocol messages, and the
 >    scenarios involving more than two communicating parties.  The Token
 >    Binding message format is defined using TLS specification language:
 >
 > enum {
 >     rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255)
 > } TokenBindingKeyParameters;

add comment on above:

/* imported from [I-D.ietf-tokbind-negotiation] */

 >
 > struct {
 >     opaque modulus<1..2^16-1>;
 >     opaque publicexponent<1..2^8-1>;
 > } RSAPublicKey;
 >
 > struct {
 >     opaque point <1..2^8-1>;
 > } ECPoint;
 >
 > enum {
 >     provided_token_binding(0), referred_token_binding(1), (255)
 > } TokenBindingType;
 >
 > struct {
 >     TokenBindingKeyParameters key_parameters;
 >     select (key_parameters) {
 >         case rsa2048_pkcs1.5:
 >         case rsa2048_pss:
 >             RSAPublicKey rsapubkey;
 >         case ecdsap256:
 >             ECPoint point;
 >     }

missing a semi-colon, should be:

};

 > } TokenBindingID;
 >
 > enum {
 >     (255)                       // No initial ExtensionType registrations
 > } ExtensionType;

comments in TLS presentation language are: /* . . . */
see https://tools.ietf.org/html/draft-ietf-tls-tls13#section-4.2

 >
 > struct {
 >     ExtensionType extension_type;
 >     opaque extension_data<0..2^16-1>;
 > } Extension;
 >
 > struct {
 >     TokenBindingType tokenbinding_type;
 >     TokenBindingID tokenbindingid;
 >     opaque signature<0..2^16-1>;// Signature over the exported keying
 >material value
 >     Extension extensions<0..2^16-1>;
 > } TokenBinding;
 >
 > struct {
 >     TokenBinding tokenbindings<0..2^16-1>;
 > } TokenBindingMessage;

is it legit for a TokenBindingMessage to be an empty sequence as implied
by the "tokenbindings<0..2^16-1>" declaration? no, it is not, see last
paragraph below in this section.

[this sort of inconsistency seems to also exist in RFC5246 so I am
doubting it is something to worry about.]

The below paragraphs appear to be client-side processing rules, yes? I
suggest identifying them as such.

 >    The Token Binding message consists of a series of TokenBinding
 >    structures containing the type of the token binding, the
 >    TokenBindingID, a signature over the exported keying material (EKM)
 >    value, optionally followed by Extension structures.
 >
 >    This document defines two token binding types: provided_token_binding
 >    used to establish a Token Binding when connecting to a server, and
 >    referred_token_binding used when requesting tokens to be presented to
 >    a different server.  Token Binding over HTTP [I-D.ietf-tokbind-https]
 >    describes Token Binding between multiple communicating parties: User
 >    Agent, Identity Provider and Relying Party.  See also Section 7.1
 >
 >    When an rsa2048_pkcs1.5 or rsa2048_pss key is used,
 >    TokenBinding.signature contains the signature generated using,
 >    respectively, the RSASSA-PKCS1-v1_5 or RSASSA-PSS signature scheme
 >    defined in [RFC3447].  RSAPublicKey.modulus and
 >    RSAPublicKey.publicexponent contain the length-prefixed modulus and
 >    exponent of the RSA public key represented in big-endian format.
 >
 >    When an ecdsap256 key is used, TokenBinding.signature contains a pair
 >    of integers, R followed by S, as defined in [ANSI.X9-62.2005].  R and
 >    S are encoded in big-endian format.  ECPoint.point contains the X
 >    coordinate followed by the Y coordinate.  The X and Y coordinates are
 >    unsigned integers encoded in big-endian format.  Future
 >    specifications may define Token Binding keys using other elliptic
 >    curves with their corresponding signature and point formats.
 >
 >    The EKM is obtained using the Keying Material Exporters for TLS
 >    defined in [RFC5705], by supplying the following input values:
 >
 >    o  Label: The ASCII string "EXPORTER-Token-Binding" with no
 >       terminating NUL.
 >
 >    o  Context value: NULL (no application context supplied).
 >
 >    o  Length: 32 bytes.

the below 2 parags are essentially server-side processing rules -- fold
them into the next section and rename it "server processing model"?

 >    An implementation MUST ignore any unknown extensions.  Initially, no
 >    extension types are defined (see Section 7.2).  One of the possible
 >    uses of extensions envisioned at the time of this writing is
 >    attestation: cryptographic proof that allows the server to verify
 >    that the Token Binding key is hardware-bound.  The definitions of
 >    such Token Binding protocol extensions are outside the scope of this
 >    specification.
 >
 >    At least one TokenBinding MUST be included in the Token Binding
 >    message.  The signature algorithm and key length used in the
 >    TokenBinding MUST match the parameters negotiated via
 >    [I-D.ietf-tokbind-negotiation].  The client SHOULD generate and store
 >    Token Binding keys in a secure manner that prevents key export.  In
 >    order to prevent cooperating servers from linking user identities,
 >    different keys SHOULD be used by the client for connections to
 >    different servers,

s/cooperating servers/colluding servers/

                          according to the token scoping rules of the
 >    application protocol.
 >
 > 4.  Establishing a TLS Token Binding

s/Token Binding/Token Binding ID/

this section is written from the perspective of the server side upon
receipt of an app layer msg containing a TokenBindingMessage, perhaps be
more explicit and have an intro sentence like..

Upon receipt by the server of a client's TokenBindingMessage via the
application layer protocol, the server performs these checks:

 >    The triple handshake vulnerability in TLS 1.2 and older TLS versions
 >    affects the security of the Token Binding protocol, as described in
 >    the "Security Considerations" section below.  Therefore, the server
 >    MUST NOT negotiate the use of the Token Binding protocol with these
 >    TLS versions, unless the server also negotiates Extended Master
 >    Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS
 >    extensions.

the above admonition is TLS-specific and is already addressed in
[I-D.ietf-tokbind-negotiation] so remove it?

 >    The server MUST terminate the connection if the use of the Token
 >    Binding protocol was not negotiated, but the client sends the Token
 >    Binding message.

s/not negotiated/not negotiated at the TLS layer/

 >                       If the Token Binding type is
 >    "provided_token_binding", the server MUST verify that the signature
 >    algorithm (including elliptic curve in the case of ECDSA) and key
 >    length in the Token Binding message match those negotiated via
 >    [I-D.ietf-tokbind-negotiation].  In the case of a mismatch, the
 >    server MUST terminate the connection.

suggest..

OLD:
the signature algorithm (including elliptic curve in the case of ECDSA)
and key length in the Token Binding message match those

NEW:
the key parameters value in the Token Binding object match that

 >                                              As described in
 >    [I-D.ietf-tokbind-https], Token Bindings of type
 >    "referred_token_binding" may have different key parameters than those
 >    negotiated via [I-D.ietf-tokbind-negotiation].

rather than "negotiated via [I-D.ietf-tokbind-negotiation]", you mean
"negotiated with this server." -- yes ?

suggest:

Token Bindings of types other than "provided_token_binding" may have
different key parameters than those negotiated for the current provided
TLS Token Binding ID.

 >
 >    If the Token Binding message does not contain at least one
 >    TokenBinding structure, or the signature contained in a TokenBinding
 >    structure is invalid, the server MUST terminate the connection.

make the next sentence a new parag:

 >    Otherwise, the TLS Token Binding is successfully established and its
 >    ID can be provided to the application for security token validation.

suggested enhancement:

Otherwise, the Token Binding IDs for the token binding
context between this client and server are successfully
established. The TokenBindingID structure(s) are noted by
the client application, and they are extracted from the
TokenBindingMessage and noted by the server side
application. The application may then use the Token Binding
IDs for bound security token creation and validation (e.g., as in
[I-D.ietf-tokbind-https]), or other application uses as appropriate.

given the above, it seems section 5 below seems superfluous to me:

 >
 > 5.  TLS Token Binding ID Format
 >
 >    The ID of the TLS Token Binding established as a result of Token
 >    Binding message processing is a binary representation of the
 >    following structure:
 >
 >
 >    struct {
 >        TokenBindingKeyParameters key_parameters;
 >        select (key_parameters) {
 >            case rsa2048_pkcs1.5:
 >            case rsa2048_pss:
 >                RSAPublicKey rsapubkey;
 >            case ecdsap256:
 >                ECPoint point;
 >        }
 >    } TokenBindingID;
 >
 >
 >    TokenBindingID contains the key parameters negotiated via
 >    [I-D.ietf-tokbind-negotiation].  TLS Token Binding ID can be obtained
 >    from the TokenBinding structure described in the "Token Binding
 >    Protocol Message" section of this document by discarding the token
 >    binding type, signature and extensions.  TLS Token Binding ID will be
 >    available at the application layer and used by the server to generate
 >    and verify bound tokens.

 > 6.  Security Token Validation

Security Token Binding and Validation

 >    Security tokens can be bound to the TLS layer either by embedding the
 >    Token Binding ID in the token, or by maintaining a database mapping
 >    tokens to Token Binding IDs.  The specific method of generating bound
 >    security tokens is application-defined and beyond the scope of this
 >    document.

suggested rewrite:

In general, application layer security tokens are bound to the
underlying TLS connection by either embedding the connection's
TokenBindingID within the security token, or by the application
maintaining a mapping of security tokens to TokenBindingIDs. The
specific method of binding application security tokens to underlying
TLS connection(s) is application-defined and beyond the scope of this
specification.

 >    Upon receipt of a security token, the server attempts to retrieve TLS
 >    Token Binding ID information from the token and from the TLS
 >    connection with the client.  Application-provided policy determines
 >    whether to honor non-bound (bearer) tokens.  If the token is bound
 >    and a TLS Token Binding has not been established for the client
 >    connection, the server MUST discard the token.  If the TLS Token
 >    Binding ID for the token does not match the TLS Token Binding ID
 >    established for the client connection, the server MUST discard the
 >    token.

Upon receipt of a bound security token, the server-side application
extracts the TokenBindingID(s) from the bound security token and from
the TLS connection with the client. Application-specific policy
determines whether to honor unbound (i.e., bearer) security tokens.
If the security token is bound and a Token Binding has not been
established for the client connection, the server MUST discard the
security token. If the TokenBindingID within the token does not match
the TokenBindingID established for the client connection, the server
MUST discard the token.

though: what's the rationale for only discarding tokens and not doing
anything further? see S7 above.

 > 7.  IANA Considerations
<snip>
 >
 > 8.  Security Considerations
 >
 > 8.1.  Security Token Replay
 >
 >    The goal of the Token Binding protocol is to prevent attackers from
 >    exporting and replaying security tokens, thereby impersonating
 >    legitimate users and gaining access to protected resources.  Bound
 >    tokens can still be replayed by the malware present in the User
 >    Agent.  In order to export the token to another machine and
 >    successfully replay it, the attacker also needs to export the
 >    corresponding private key.  Token Binding private keys are therefore
 >    high-value assets and SHOULD be strongly protected, ideally by
 >    generating them in a hardware security module that prevents key
 >    export.
 >
 >    The manner in which a token is bound to the TLS layer is application-
 >    defined and beyond the scope of this document.  However, the
 >    resulting bound token needs to be integrity-protected, so that an
 >    attacker cannot remove the binding or substitute a Token Binding ID
 >    of their choice without detection.
 >
 > 8.2.  Downgrade Attacks
 >
 >    The Token Binding protocol is only used when negotiated via
 >    [I-D.ietf-tokbind-negotiation] within the TLS handshake.  TLS
 >    prevents active attackers from modifying the messages of the TLS
 >    handshake, therefore it is not possible for the attacker to remove or
 >    modify the Token Binding Negotiation TLS Extension used to negotiate
 >    the Token Binding protocol and key parameters.  The signature
 >    algorithm and key length used in the TokenBinding of type
 >    "provided_token_binding" MUST match the parameters negotiated via
 >    [I-D.ietf-tokbind-negotiation].

suggest:

TLS prevents active attackers from modifying the messages of the TLS
handshake, therefore it is not possible for the attacker to remove or
modify the Token Binding Negotiation TLS Extension used to negotiate
the Token Binding protocol version and key parameters. The key
parameters used in TokenBindingMessage.TokenBinding structures of type
"provided_token_binding" MUST match the key parameters negotiated via
[I-D.ietf-tokbind-negotiation].

 >
 > 8.3.  Privacy Considerations
 >
 >    The Token Binding protocol uses persistent, long-lived TLS Token
 >    Binding IDs.  To protect privacy, TLS Token Binding IDs are never
 >    transmitted in clear text and can be reset by the user at any time,
 >    e.g. when clearing browser cookies.  Some applications offer a
 >    special privacy mode where they don't store or use tokens supplied by
 >    the server, e.g.  "in private" browsing.  When operating in this
 >    special privacy mode, applications SHOULD use newly generated Token
 >    Binding keys and delete them when exiting this mode, or else SHOULD
 >    NOT negotiate Token Binding at all.
 >
 >    In order to prevent cooperating servers from linking user identities,
 >    different keys SHOULD be used by the client for connections to
 >    different servers, according to the token scoping rules of the
 >    application protocol.

the above admonition (paragraph) should be up above where generation of
the token binding key pair is stipulated.

 >
 >    A server can use tokens and Token Binding IDs to track clients.
 >    Client applications that automatically limit the lifetime of tokens
 >    to maintain user privacy SHOULD apply the same validity time limits
 >    to Token Binding keys.
 >
<snip>

---

From: Andrei Popov <[email-masked]>
Date: Fri, 1 Apr 2016 00:16:49 +0000

Hi Jeff,

Thanks for the review.

S1. If Dirk is OK with adding referred_token_binding type and its IANA registration to HTTPSTB, then when it's done, I will remove from TBPROTO. Although the need for referred_token_binding is general enough that I would be fine keeping it in TBPROTO.

S2. What is the use case? A client generating its own token and binding it to the client's TB key?

S3. TBPROTO already describes the specific parameters of the TLS exporter, including the context, per RFC5705, see TBPROTO section 3.

S5. Token Binding is a protocol; I don't see a need to describe APIs.

S6a. "Reset" means "deleted" in this case, perhaps it will be more clear if I use the latter term. Servers simply need to validate the binding: either the token is acceptable, or not. If not, client auth is re-done and a new bound token is generated. This is a flow that today's Web apps support.

S6b. TBPROTO has a new privacy consideration for this: 
" A server can use tokens and Token Binding IDs to track clients.
   Client applications that automatically limit the lifetime of tokens
   to maintain user privacy SHOULD apply the same validity time limits
   to Token Binding keys."

S7. Servers handle invalid tokens today; TBPROTO describes new cases where a bound token must be considered invalid. At least in our deployment experience so far, TB validation failures are auto-handled by the existing application logic with no change.

S8. Pull request will be appreciated:).

S9. How about "Token Binding IDs MUST never be transmitted in clear text"?

S10. We've discussed this before and I would prefer to keep the EMS mantra:). If more folks push for this, I'll make the change.

S11. TB type was removed from TB ID because it's contextual: the same TB is "provided" to the RP and "referred" to the IDP. Now if the IDP includes this "referred" TB ID in the token, the RP will see that the first byte does not match. At least in our implementation, this change reduces the number of SW components that need to understand the structure of TB IDs.

S12. I think so, at least I don't see a reason why we would not do this. I did not make this change in -05, because I'd like to give folks time to think about this and speak up if they see a problem.

Regarding the editorial comments, but I'd appreciate pull requests:).

Thanks,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Wednesday, March 30, 2016 8:59 PM
To: IETF Tokbind WG <[email-masked]>
Subject: [Unbearable] comments on -tokbind-protocol-05 aka TBPROTO

Substantive comments:

S1. need to migrate the referred_token_binding type and its IANA registration over to -tokbind-https aka HTTPSTB. see..

   Re: [Unbearable] -tokbind-protocol-04: verifying signature(s)
   in TokenBindingMessage.TokenBinding?
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2funbearable%2fcurrent%2fmsg00470.html&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ceb9106880c0f43c8f1fd08d35918e032%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QO3CyTKGt%2f%2f%2bvTudCFpoVlIAWrCvBVo0WNqCPuhqiBE%3d>

As part of this, we may want to explicitly state that defining the semantics of TokenBindingMessages containing more than one provided TokenBinding, as well as allocating new TokenBindingType value(s), is left to applications.

S2. TBPROTO focuses on the server side binding TBIDs to "security tokens".
However, there are occasions in some protocols/apps where the client side is obliged to bind objects to the TLS layer. See for example <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fw3c.github.io%2fwebauthn%2f%23sec-client-data&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ceb9106880c0f43c8f1fd08d35918e032%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tKSoFC0O3WzmmLdTFN2NoMETyeaNFGibJSL9Vv8%2fXSM%3d>. TBPROTO should more clearly explain that either the client or server side may bind TBIDs into objects (tokens, messages, whatever) and either side may be obliged to validate such objects, depending on application use case(s).

S3. It seems that TBPROTO intends to be a general purpose app-layer means for generating and agreeing on TBIDs, i.e., it is not just for HTTP; it seems to serve the purpose of mitigating the need for different app-layers to re-invent such a mechanism on their own. In doing so, it arguably is acting as general-purpose packaging of the TLS keying material exporter, and insulating other app-layer designers from the vagaries described in the last parag of the sec cons in RFC5705..

S6a. How TBIDs are "reset" is not described. Presumably, this is accomplished by the client allocating a new key pair for a server, resigning EKM, and including the new values in the "next"
TokenBindingMessage sent to the server, and servers need to be vigilant about noticing new TBIDs and re-binding application security tokens/messages as appropriate, yes?

S6b. Our Security AD verbally expressed to some of us (at IETF-94?) that simply saying "TBIDs can be reset by the user at any time" is insufficient guidance to app-layer designers regarding a privacy-preserving utilization of TBPROTO. What else might be added? Perhaps suggestion(s) that the app-layer periodically auto-reset TBIDs?

S7. Section 6 Security Token Validation specifies conditions (eg incorrect
TBID) upon which the server "MUST discard the token". Are there not a range of application behaviors that might occur, e.g., terminating the application session? Or, is this particular behavior defined in order to accommodate resetting of TBIDs by the client-side whereupon there may be a race condition before all the server-issued bound app sec tokens contain the updated TBID? Is this behavior appropriate for all apps in all cases?
what if an incorrect bound TBID is being caused by a MITM?

S8. Section 8.2 Security Token Replay is fairly light on details regarding how an application layer can utilize TBPROTO to detect MITM attacks, perhaps appropriately generalizing and including the 2nd parag from [2] would help readers better understand how this would work?

S9. I would not say "TLS Token Binding IDs are never transmitted in clear text.." -- this could easily occur in an HTTP-based web app that inadvertently leaks cookies, e.g. by retrieving some image over plain http. addressing this implies adding sec cons wrt such risks, eg "apps need to take precautions to ensure bound sec tokens/messages are not 'leaked' over insecure connections such as can occur due to non-https
link(s) lurking in a web app, e.g., an image load. HTTP-based applications should employ techniques such as HSTS and HPKP in order to guard against such situations."

S10. I would remove the triple-handshake admonition in section 4, and perhaps the one in sec cons, but in any case add to sec cons that there are important sec cons regarding the underlying TLS connection in [I-D.ietf-tokbind-negotiation] that could mitigate the app-layer's TB-based security benefits if they are not heeded.

S11. Regarding the design decision: TokenBindingType is not within TokenBindingID -- it is within the enclosing TokenBinding because TokenBindingIDs (TBIDs) may be conveyed in TBMSG as either provided_ or some other app-layer-defined TBType. If the app-layer has defined additional TBType(s), the server-side would want to remember each TBID's type, yes?

S12. Perhaps spec should stipulate "server must ignore TBTypes it does not understand" -- or not?

[1] https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc5929%23section-7&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ceb9106880c0f43c8f1fd08d35918e032%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7Rtq3b6tY8SDfgJzEXov52ed1TlmhIsiokvWFhPuu7s%3d

[2] <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-tokbind-https-02%23section-4.4&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ceb9106880c0f43c8f1fd08d35918e032%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=yl4SXEzdjflkb26Y7vdiAjGqlsOm8eELhM5C6gjvcFo%3d>

E1. the mechanics of verifying the signature(s) in a TokenBindingMessage are not spec'd in detail -- experienced crypto folk may know what to do, but others may not.

E2. ought to clearly delineate "server processing model" and "client processing model". (e.g. see https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2frfc6797&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ceb9106880c0f43c8f1fd08d35918e032%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=o549jo6lq%2fNiA0CM20JVit7j0YfXaiLt7Rh28IKbM1Q%3d)

E3. section "1. Introduction" and section "2. token binding protocol overview" are quite similar -- perhaps they could be combined?

E4. If section 3 and 4 are massaged per E2, section 5 becomes superfluous (it seemed to in my experimenting).

E4. the security considerations section contains RFC2119 requirements language -- some downstream reviews may frown on this.

E5. TBPROTO in and of itself does not "prevent" export and replay of app security tokens -- rather it facilitates detection of such occurances.

E6. Terminology is fairly loose, e.g. terms such as "token", "security token", "bound token", "bound security token" are not used as consistently as they could be.

E7. Various spec portions could benefit from further wordsmithing -- suggestions are inline below...

<snip>
<snip>

 > 2.  Token Binding Protocol Overview

this section largely duplicates the Introduction -- could the intro be trimmed way down and then this section effectively provides the underlying details that are summarized in the Intro?

 >    the Token Binding key.  This negotiation does not require additional

wrt "the parameters (signature algorithm, length)" -- this is now effectively referred to as "key parameters" yes?

 >    protocol data in TLS application_data records.

wrt... "The Token Binding message is sent with the application protocol data in TLS application_data records"

...in other words, after Token Binding negotiation during TLS handshake [I-D.ietf-tokbind-negotiation], the Token Binding msg is created by the client and conveyed to the server in the app layer protocol which is running over TLS within whose context the token binding ID was established. Yes?

perhaps re-state.

add comment on above:

};

 >     (255)                       // No initial ExtensionType registrations

comments in TLS presentation language are: /* . . . */ see https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-tls-tls13%23section-4.2&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ceb9106880c0f43c8f1fd08d35918e032%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=syRBZbc35znWJx2yjbbHPcrAbOS%2fD4drLMvaPSP6DtE%3d

 >     TokenBinding tokenbindings<0..2^16-1>;

is it legit for a TokenBindingMessage to be an empty sequence as implied by the "tokenbindings<0..2^16-1>" declaration? no, it is not, see last paragraph below in this section.

[this sort of inconsistency seems to also exist in RFC5246 so I am doubting it is something to worry about.]

The below paragraphs appear to be client-side processing rules, yes? I suggest identifying them as such.

 >    o  Context value: NULL (no application context supplied).

the below 2 parags are essentially server-side processing rules -- fold them into the next section and rename it "server processing model"?

this section is written from the perspective of the server side upon receipt of an app layer msg containing a TokenBindingMessage, perhaps be more explicit and have an intro sentence like..

 >    Secret [RFC7627] and Renegotiation Indication [RFC5746] TLS

the above admonition is TLS-specific and is already addressed in [I-D.ietf-tokbind-negotiation] so remove it?

suggest..

OLD:
the signature algorithm (including elliptic curve in the case of ECDSA) and key length in the Token Binding message match those

NEW:

 >    negotiated via [I-D.ietf-tokbind-negotiation].

rather than "negotiated via [I-D.ietf-tokbind-negotiation]", you mean "negotiated with this server." -- yes ?

suggest:

Token Bindings of types other than "provided_token_binding" may have different key parameters than those negotiated for the current provided TLS Token Binding ID.

suggested enhancement:

Otherwise, the Token Binding IDs for the token binding context between this client and server are successfully established. The TokenBindingID structure(s) are noted by the client application, and they are extracted from the TokenBindingMessage and noted by the server side application. The application may then use the Token Binding IDs for bound security token creation and validation (e.g., as in [I-D.ietf-tokbind-https]), or other application uses as appropriate.

suggested rewrite:

In general, application layer security tokens are bound to the underlying TLS connection by either embedding the connection's TokenBindingID within the security token, or by the application maintaining a mapping of security tokens to TokenBindingIDs. The specific method of binding application security tokens to underlying TLS connection(s) is application-defined and beyond the scope of this specification.

 >    established for the client connection, the server MUST discard the

Upon receipt of a bound security token, the server-side application extracts the TokenBindingID(s) from the bound security token and from the TLS connection with the client. Application-specific policy determines whether to honor unbound (i.e., bearer) security tokens.
If the security token is bound and a Token Binding has not been established for the client connection, the server MUST discard the security token. If the TokenBindingID within the token does not match the TokenBindingID established for the client connection, the server MUST discard the token.

though: what's the rationale for only discarding tokens and not doing anything further? see S7 above.

<snip>

suggest:

TLS prevents active attackers from modifying the messages of the TLS handshake, therefore it is not possible for the attacker to remove or modify the Token Binding Negotiation TLS Extension used to negotiate the Token Binding protocol version and key parameters. The key parameters used in TokenBindingMessage.TokenBinding structures of type "provided_token_binding" MUST match the key parameters negotiated via [I-D.ietf-tokbind-negotiation].

 >    different servers, according to the token scoping rules of the

the above admonition (paragraph) should be up above where generation of the token binding key pair is stipulated.

<snip>

_______________________________________________
Unbearable mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ceb9106880c0f43c8f1fd08d35918e032%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hmtJxiRucUApCw9TYg9cC42LHEvmkWxv0AmHinFnpJc%3d