Subject: [Unbearable] -protocol-04 & -https-02: MITM TBID substitution in bound security tokens?

From: =JeffH <[email-masked]>
Date: Thu, 3 Mar 2016 13:53:26 -0800

summary:  if TokenBindingIDs (TBIDs) are contained within application 
security tokens (e.g., authn cookies, OIDC ID Tokens, SAML authn assertions, 
etc), or by reference, without the binding to said security tokens being 
integrity-protected in some fashion, then what prevents a man-in-the-middle 
(MITM) entity, as contextually defined in S 4.5 of -tokbind-https-02, from 
(in the simplest case) performing a cut-and-paste substitution of their TBID 
with the server, into said security token before conveying it to the server?

This sec cons wrinkle doesn't seem to be addressed in either spec -- a 
security considerations suggestion is at the end below.

HTH,

=JeffH

details:

 From HTTPSTB
https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-4.5:

 > 4.5. Securing Federated Sign-On Protocols
 >
 >    [...]
 >
 >    o  A man-in-the-middle is allowed to intercept the connection between
 >       client and Token Consumer or between Client and Token Provider (or
 >       both).
 >
 >    The goal is to detect the presence of the man-in-the-middle in these
 >    scenarios.
 >
 >    First, consider a man-in-the-middle between the client and the Token
 >    Provider.  Recall that we assume that the client possesses a bound
 >    authentication token (e.g., cookie) for the Token Provider.  The man-
 >    in-the-middle can intercept and modify any message sent by the client
 >    to the Token Provider, and any message sent by the Token Provider to
 >    the client.  (This means, among other things, that the man-in-the-
 >    middle controls the Javascript running at the client in the origin of
 >    the Token Provider.)  It is not, however, in possession of the
 >    client's Token Binding key. Therefore, it can either choose to
 >    replace the Token Binding key in requests from the client to the
 >    Token Provider, and create a Token-Binding header that matches the
 >    TLS connection between the man-in-the-middle and the Token Provider;
 >    or it can choose to leave the Token-Binding header unchanged.
 >
 >    If it chooses the latter, the signature in the Token Binding message
 >    (created by the original client on the exported keying material (EKM)
 >    for the connection between client and man-in-the-middle) will not
 >    match the EKM between man-in-the-middle and the Token Provider.
 >
 >    If it chooses the former (and creates its own signature, with its own
 >    Token Binding key, over the EKM for the connection between man-in-
 >    the-middle and Token Provider), then the Token Binding message will
 >    match the connection between man-in-the-middle and Token Provider,
 >    but the Token Binding key in the message will not match the Token
 >    Binding key that the client's authentication token is bound to.

In the case where the TBID is contained directly within the authn token, 
what is preventing the MITM from substituting its own TBID, for the
MITM's token-bound TLS session with the Token Provider, within the
client's authn token? See also S 6 (below) from TBPROTO --

 >From TBPROTO
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04#section-6 :

 > 6. Security Token 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.
 >
 >    [...]

Although I agree with the latter statement above wrt details of generating 
bound security tokens, are there not some overall security considerations 
that TBPROTO could/should mention? E.g..

   The manner in which a Token Binding ID is bound to an application
   security token is application-defined, however, there are overall
   security considerations which the application developers and deployers
   should be aware of: it should not be possible for a MITM to substitute
   another TBID for the one bound to an app security token without
   detection. This can be accomplished in various ways, e.g., a
   directly-bound security token can be cryptographically integrity-
   protected, or, the TBID may be bound to the security token by reference
   in a fashion that is not susceptible to direct substitution.

end

---

From: Andrei Popov <[email-masked]>
Date: Fri, 4 Mar 2016 00:09:26 +0000

Yes, this looks like a useful security consideration. Unless folks object, I will add this in the next revision.

Thanks,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Thursday, March 3, 2016 1:53 PM
To: IETF Tokbind WG <[email-masked]>
Subject: [Unbearable] -protocol-04 & -https-02: MITM TBID substitution in bound security tokens?

summary:  if TokenBindingIDs (TBIDs) are contained within application security tokens (e.g., authn cookies, OIDC ID Tokens, SAML authn assertions, etc), or by reference, without the binding to said security tokens being integrity-protected in some fashion, then what prevents a man-in-the-middle
(MITM) entity, as contextually defined in S 4.5 of -tokbind-https-02, from (in the simplest case) performing a cut-and-paste substitution of their TBID with the server, into said security token before conveying it to the server?

This sec cons wrinkle doesn't seem to be addressed in either spec -- a security considerations suggestion is at the end below.

HTH,

=JeffH

details:

 From HTTPSTB
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-tokbind-https-02%23section-4.5%3a&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c0994d7e8f3ac46a1cdaa08d343ae4e0c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=OrOoi9teVWJ6htB086I6nCu7i7jleChQrV1po7ZMoDE%3d

 > 4.5. Securing Federated Sign-On Protocols  >
 >    [...]
 >

In the case where the TBID is contained directly within the authn token, what is preventing the MITM from substituting its own TBID, for the MITM's token-bound TLS session with the Token Provider, within the client's authn token? See also S 6 (below) from TBPROTO --

 >    security tokens is application-defined and beyond the scope of this

Although I agree with the latter statement above wrt details of generating bound security tokens, are there not some overall security considerations that TBPROTO could/should mention? E.g..

end

_______________________________________________
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%7c0994d7e8f3ac46a1cdaa08d343ae4e0c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iYoMPO22FAoGFtrAaczPCvW7q8qoP5A6%2beI52XCZ%2bfA%3d

---

From: Andrei Popov <[email-masked]>
Date: Fri, 25 Mar 2016 22:10:00 +0000

Yes, the token needs to be integrity-protected. Will add this security consideration to TBPROTO.

Thanks,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Thursday, March 3, 2016 1:53 PM
To: IETF Tokbind WG <[email-masked]>
Subject: [Unbearable] -protocol-04 & -https-02: MITM TBID substitution in bound security tokens?

HTH,

=JeffH

details:

 From HTTPSTB

end