Subject: [kitten] Channel Bindings Discussion

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 16 Aug 2010 17:40:08 +0300

Hi all, 

As mentioned recently, the OpenID - SASL I-D authors (Simon, Eliot,
Hank, and myself) discussed the topic of channel bindings offlist. Since
the topic resurfaced on the mailing list we thought it would be useful
to share our private conversation with the rest of the group. 

Ciao
Hannes

---------------------

From: Hannes Tschofenig <[email-masked]>
Subject: OpenID & SASL: Channel Bindings
To: Simon Josefsson <[email-masked]>, Eliot Lear <[email-masked]>,
        [email-masked]
Date: Thu, 08 Jul 2010 14:47:50 +0300

Hi all,

I had a brief chat with Eliot two days ago and we ran into the topic
of "channel bindings". I thought I should share my opinion with you.

First, I have to say that I find the writeup by Nico in RFC 5056 hard
to understand. I re-read it today and it still confuses me. I also
have the history of the EAP work in my head, which (due to the name
collision) makes everything just more complicated.

Ignoring what I said in the previous paragraph, let me start slightly
differently to understand what you guys worry about (based on the
figure from the draft):

                                    +-----------+
                                    |           |
                                   >|  Relying  |
                                  / |  Party    |
                                //  |           |
                              //    +-----------+
                            //            ^
                   OpenID //           +--|--+
                        //             | O|  |
                       /             S | p|  |
                     //              A | e|  |
                   //                S | n|  |
                 //                  L | I|  |
               //                      | D|  |
             </                        +--|--+
      +------------+                      v
      |            |                 +----------+
      |  OpenID    |   OpenID        |          |
      |  Provider  |<--------------->|  Client  |
      |            |                 |          |
      +------------+                 +----------+

We assume that TLS is used between the client and the relying party with
server-side autnentication.
The certificate used for this purpose will show some identity, let us
call it RP_TLS_X.

Then, we might have TLS between the Client and the OpenID provider but
that largely depends on the authentication mechanism being used.

Furthermore, we have authentication of the RP to the OP (and vice versa)
at the OpenID "application layer". The RP will have some identity, let
us call it RP_OpenID_Y.

Now, I believe you guys worry about the linkage between the TLS channel
(used between the client and the RP) and the OpenID identity used by the
RP.

Is this correct?

Ciao
Hannes

From: Simon Josefsson <[email-masked]>
Subject: Re: OpenID & SASL: Channel Bindings
To: Hannes Tschofenig <[email-masked]>
Cc: Eliot Lear <[email-masked]>,  [email-masked]
Date: Thu, 08 Jul 2010 15:03:31 +0200

Hannes Tschofenig <[email-masked]> writes:

> Hi all,
>
> I had a brief chat with Eliot two days ago and we ran into the topic
> of "channel bindings". I thought I should share my opinion with you.
>
> First, I have to say that I find the writeup by Nico in RFC 5056 hard
> to understand. I re-read it today and it still confuses me. I also
> have the history of the EAP work in my head, which (due to the name
> collision) makes everything just more complicated.

Hi.  Yes, I have also found that document difficult to understand, and I
participated in the discussions around it.  I don't envy anyone else
trying to understand it.

> Ignoring what I said in the previous paragraph, let me start slightly
> differently to understand what you guys worry about (based on the
> figure from the draft):

Let me also say that my answer below is what _I_ worry about: I don't
know for what purpose Nico would like to see support for channel
bindings.

>
>                                     +-----------+
>                                     |           |
>                                    >|  Relying  |
>                                   / |  Party    |
>                                 //  |           |
>                               //    +-----------+
>                             //            ^
>                    OpenID //           +--|--+
>                         //             | O|  |
>                        /             S | p|  |
>                      //              A | e|  |
>                    //                S | n|  |
>                  //                  L | I|  |
>                //                      | D|  |
>              </                        +--|--+
>       +------------+                      v
>       |            |                 +----------+
>       |  OpenID    |   OpenID        |          |
>       |  Provider  |<--------------->|  Client  |
>       |            |                 |          |
>       +------------+                 +----------+
>
> We assume that TLS is used between the client and the relying party
> with server-side autnentication.  The certificate used for this
> purpose will show some identity, let us call it RP_TLS_X.

Right.

> Then, we might have TLS between the Client and the OpenID provider but
> that largely depends on the authentication mechanism being used.

Yes.  Mentally, I try to ignore what happens outside of the Client<->RP
communication because it is authentication mechanism specific.  Whether
it uses TLS or not is not relevant.  So to me, the only relevant TLS
channel to worry about is the Client<->RP channel.

> Furthermore, we have authentication of the RP to the OP (and vice
> versa) at the OpenID "application layer". The RP will have some
> identity, let us call it RP_OpenID_Y.
>
> Now, I believe you guys worry about the linkage between the TLS
> channel (used between the client and the RP) and the OpenID identity
> used by the RP.
>
> Is this correct?

I'm not sure that is really the same that I worry about.  I worry about
a MITM between Client and RP.  There are two ways to detect the MITM:

1) Require server certificate validation by the client.  This is the
traditional solution, but in practice it is quite weak because clients
either trust a gazillion of CAs out there (which is a bad idea) that
easily allows a MITM to acquire a fraudulent certificate or the end-user
manually inspects the certificate and clicks OK (in practice probably
even worse given that end-users can't be trusted with these decisions in
general).  There is no automatic and secure way for clients to learn the
trust anchor used by the server.

2) Both client and RP hashes (or somehow mixes in) the channel binding
data into the authentication process in a way that if the channel
binding data does NOT match, authentication will fail.

SASL PLAIN uses approach 1).  SASL SCRAM uses approach 2).  For SCRAM,
achieving 2 is easy because there is a shared secret between client and
server, and each peer can HMAC its channel binding and the peer can
verify the HMAC and then any MITM is detected.

I would like to have support for channel bindings in the OpenID (and
SAML) SASL mechanism because I believe 2) provides stronger protection
than 1).  However, I also realize that given how OpenID works, it _may_
be impossible without modifying the IdP.  But I don't think we have
proven that yet.  Maybe we can use the returns_to URL to store the
channel binding data, and allow Client+RP to parse and validate that.

Is this clearer?

/Simon

From: "Hannes Tschofenig" <[email-masked]>
Subject: Re: OpenID & SASL: Channel Bindings
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Fri, 09 Jul 2010 10:56:52 +0200

Hi Simon, 

I noticed that you and Eliot had exchanged some emails about this topic
already (and they all ended up in my spam folder). I will have to browse
through them. I will also have to read SASL SCRAM to be sure I
understand your concern. 

However, with the concern you describe it seems that you are more
looking into something related to cryptographic bindings, see
http://www.springerlink.com/content/8qv4qncf4fk106pg/. 

I doubt that you will easily get around verifying the server provided
certificate but you could  check whether the identities provided at the
different layers match, namely RP_TLS_X and RP_OpenID_Y. Doing this
would at least ensure that the end points are the same, which is what
you are verifying when you hash data from both layers together. 

A separate, but important aspect, is to figure out what are the
pre-conditions for a MITM attack to work and whether the threat is high
enough to justify a solution. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Thu, 08 Jul 2010 15:03:31 +0200
> Von: Simon Josefsson <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>
> CC: Eliot Lear <[email-masked]>, [email-masked]
> Betreff: Re: OpenID & SASL: Channel Bindings

> Hannes Tschofenig <[email-masked]> writes:
> 
> > Hi all,
> >
> > I had a brief chat with Eliot two days ago and we ran into the topic
> > of "channel bindings". I thought I should share my opinion with you.
> >
> > First, I have to say that I find the writeup by Nico in RFC 5056
hard
> > to understand. I re-read it today and it still confuses me. I also
> > have the history of the EAP work in my head, which (due to the name
> > collision) makes everything just more complicated.
> 
> Hi.  Yes, I have also found that document difficult to understand, and
I
> participated in the discussions around it.  I don't envy anyone else
> trying to understand it.
> 
> > Ignoring what I said in the previous paragraph, let me start
slightly
> > differently to understand what you guys worry about (based on the
> > figure from the draft):
> 
> Let me also say that my answer below is what _I_ worry about: I don't
> know for what purpose Nico would like to see support for channel
> bindings.
> 
> >
> >                                     +-----------+
> >                                     |           |
> >                                    >|  Relying  |
> >                                   / |  Party    |
> >                                 //  |           |
> >                               //    +-----------+
> >                             //            ^
> >                    OpenID //           +--|--+
> >                         //             | O|  |
> >                        /             S | p|  |
> >                      //              A | e|  |
> >                    //                S | n|  |
> >                  //                  L | I|  |
> >                //                      | D|  |
> >              </                        +--|--+
> >       +------------+                      v
> >       |            |                 +----------+
> >       |  OpenID    |   OpenID        |          |
> >       |  Provider  |<--------------->|  Client  |
> >       |            |                 |          |
> >       +------------+                 +----------+
> >
> > We assume that TLS is used between the client and the relying party
> > with server-side autnentication.  The certificate used for this
> > purpose will show some identity, let us call it RP_TLS_X.
> 
> Right.
> 
> > Then, we might have TLS between the Client and the OpenID provider
but
> > that largely depends on the authentication mechanism being used.
> 
> Yes.  Mentally, I try to ignore what happens outside of the
Client<->RP
> communication because it is authentication mechanism specific.
Whether
> it uses TLS or not is not relevant.  So to me, the only relevant TLS
> channel to worry about is the Client<->RP channel.
> 
> > Furthermore, we have authentication of the RP to the OP (and vice
> > versa) at the OpenID "application layer". The RP will have some
> > identity, let us call it RP_OpenID_Y.
> >
> > Now, I believe you guys worry about the linkage between the TLS
> > channel (used between the client and the RP) and the OpenID identity
> > used by the RP.
> >
> > Is this correct?
> 
> I'm not sure that is really the same that I worry about.  I worry
about
> a MITM between Client and RP.  There are two ways to detect the MITM:
> 
> 1) Require server certificate validation by the client.  This is the
> traditional solution, but in practice it is quite weak because clients
> either trust a gazillion of CAs out there (which is a bad idea) that
> easily allows a MITM to acquire a fraudulent certificate or the
end-user
> manually inspects the certificate and clicks OK (in practice probably
> even worse given that end-users can't be trusted with these decisions
in
> general).  There is no automatic and secure way for clients to learn
the
> trust anchor used by the server.
> 
> 2) Both client and RP hashes (or somehow mixes in) the channel binding
> data into the authentication process in a way that if the channel
> binding data does NOT match, authentication will fail.
> 
> SASL PLAIN uses approach 1).  SASL SCRAM uses approach 2).  For SCRAM,
> achieving 2 is easy because there is a shared secret between client
and
> server, and each peer can HMAC its channel binding and the peer can
> verify the HMAC and then any MITM is detected.
> 
> I would like to have support for channel bindings in the OpenID (and
> SAML) SASL mechanism because I believe 2) provides stronger protection
> than 1).  However, I also realize that given how OpenID works, it
_may_
> be impossible without modifying the IdP.  But I don't think we have
> proven that yet.  Maybe we can use the returns_to URL to store the
> channel binding data, and allow Client+RP to parse and validate that.
> 
> Is this clearer?
> 
> /Simon

From: Simon Josefsson <[email-masked]>
Subject: Re: OpenID & SASL: Channel Bindings
To: "Hannes Tschofenig" <[email-masked]>
Cc: [email-masked],  [email-masked]
Date: Mon, 12 Jul 2010 14:38:45 +0200

I don't think RP_TLS_X and RP_OpenID_Y will be the same in practice.
Typically RP_TLS_X will be a SMTP/XMPP server certificate, and
RP_OpenID_Y would be a URL.  If comparison actually is useful (I'm not
sure of that), the document needs to describe how it is done.

Hm.  This discussion reminds me of the OAuth session fixation attack.
Translating the attack into our environment it would work like this:
Client X wants to send an e-mail using OpenID authentication.  Client X
is tricked into talking to attacker Y.  Attacker opens another channel
to real server Z and starts authentication, and forwards the requests
back to Client X.  Client X performs the authentication, which results
in attacker Y is authenticated as Client X to real server Z.

However, this attack is pre-empted by requiring the Client X to validate
that the server it talks to is a trusted server using TLS server
certificate validation.  I don't think it will be particulary strong in
practice -- SMTP clients rarely have trust anchors configured by the
users, but at best rely on pre-configured CAs from the software
manufacturer (which is weak security).  But at least we can claim it is
not a protocol weakness.

I could very well be missing your point... thoughts?

/Simon

"Hannes Tschofenig" <[email-masked]> writes:

> Hi Simon,
>
> I noticed that you and Eliot had exchanged some emails about this
> topic already (and they all ended up in my spam folder). I will have
> to browse through them. I will also have to read SASL SCRAM to be sure
> I understand your concern.
>
> However, with the concern you describe it seems that you are more
> looking into something related to cryptographic bindings, see
> http://www.springerlink.com/content/8qv4qncf4fk106pg/.
>
> I doubt that you will easily get around verifying the server provided
> certificate but you could check whether the identities provided at the
> different layers match, namely RP_TLS_X and RP_OpenID_Y. Doing this
> would at least ensure that the end points are the same, which is what
> you are verifying when you hash data from both layers together.
>
> A separate, but important aspect, is to figure out what are the
> pre-conditions for a MITM attack to work and whether the threat is
> high enough to justify a solution.
>
> Ciao Hannes
>
> -------- Original-Nachricht --------
>> Datum: Thu, 08 Jul 2010 15:03:31 +0200 Von: Simon Josefsson
>> <[email-masked]> An: Hannes Tschofenig
>> <[email-masked]> CC: Eliot Lear <[email-masked]>,
>> [email-masked] Betreff: Re: OpenID & SASL: Channel Bindings
>
>> Hannes Tschofenig <[email-masked]> writes:
>> 
>> > Hi all,
>> > I had a brief chat with Eliot two days ago and we ran into the
>> > topic of "channel bindings". I thought I should share my opinion
>> > with you.
>> > First, I have to say that I find the writeup by Nico in RFC 5056
>> > hard to understand. I re-read it today and it still confuses me. I
>> > also have the history of the EAP work in my head, which (due to
>> > the name collision) makes everything just more complicated.
>>  Hi.  Yes, I have also found that document difficult to understand,
>> and I participated in the discussions around it.  I don't envy
>> anyone else trying to understand it.
>> 
>> > Ignoring what I said in the previous paragraph, let me start
>> > slightly differently to understand what you guys worry about
>> > (based on the figure from the draft):
>>  Let me also say that my answer below is what _I_ worry about: I
don't
>> know for what purpose Nico would like to see support for channel
>> bindings.
>> 
>> > +-----------+ | | >| Relying | / | Party | // | | // +-----------+
>> > // ^ OpenID // +--|--+ // | O| | / S | p| | // A | e| | // S | n|
>> > | // L | I| | // | D| | </ +--|--+ +------------+ v
>> >       |            | +----------+ OpenID | OpenID | | Provider
>> >       | |<--------------->| Client | | | |
>> >       +------------+ +----------+
>> > We assume that TLS is used between the client and the relying
>> > party with server-side autnentication.  The certificate used for
>> > this purpose will show some identity, let us call it RP_TLS_X.
>>  Right.
>> 
>> > Then, we might have TLS between the Client and the OpenID provider
>> > but that largely depends on the authentication mechanism being
>> > used.
>>  Yes.  Mentally, I try to ignore what happens outside of the
>> Client<->RP communication because it is authentication mechanism
>> specific.  Whether it uses TLS or not is not relevant.  So to me,
>> the only relevant TLS channel to worry about is the Client<->RP
>> channel.
>> 
>> > Furthermore, we have authentication of the RP to the OP (and vice
>> > versa) at the OpenID "application layer". The RP will have some
>> > identity, let us call it RP_OpenID_Y.
>> > Now, I believe you guys worry about the linkage between the TLS
>> > channel (used between the client and the RP) and the OpenID
>> > identity used by the RP.
>> > Is this correct?
>>  I'm not sure that is really the same that I worry about.  I worry
>> about a MITM between Client and RP.  There are two ways to detect
>> the MITM:
>> 
>> 1) Require server certificate validation by the client.  This is the
>> traditional solution, but in practice it is quite weak because
>> clients either trust a gazillion of CAs out there (which is a bad
>> idea) that easily allows a MITM to acquire a fraudulent certificate
>> or the end-user manually inspects the certificate and clicks OK (in
>> practice probably even worse given that end-users can't be trusted
>> with these decisions in general).  There is no automatic and secure
>> way for clients to learn the trust anchor used by the server.
>> 
>> 2) Both client and RP hashes (or somehow mixes in) the channel
>> binding data into the authentication process in a way that if the
>> channel binding data does NOT match, authentication will fail.
>> 
>> SASL PLAIN uses approach 1).  SASL SCRAM uses approach 2).  For
>> SCRAM, achieving 2 is easy because there is a shared secret between
>> client and server, and each peer can HMAC its channel binding and
>> the peer can verify the HMAC and then any MITM is detected.
>> 
>> I would like to have support for channel bindings in the OpenID (and
>> SAML) SASL mechanism because I believe 2) provides stronger
>> protection than 1).  However, I also realize that given how OpenID
>> works, it _may_ be impossible without modifying the IdP.  But I don't
>> think we have proven that yet.  Maybe we can use the returns_to URL
>> to store the channel binding data, and allow Client+RP to parse and
>> validate that.
>> 
>> Is this clearer?
>> 
>> /Simon

From: "Hannes Tschofenig" <[email-masked]>
Subject: Re: OpenID & SASL: Channel Bindings
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Tue, 20 Jul 2010 11:53:46 +0200

Hi Simon, 

> I don't think RP_TLS_X and RP_OpenID_Y will be the same in practice.
> Typically RP_TLS_X will be a SMTP/XMPP server certificate, and
> RP_OpenID_Y would be a URL.  If comparison actually is useful (I'm not
> sure of that), the document needs to describe how it is done.

I also think that this is rather uncommon. While it sounds interesting
in theory it might not be worth going along the path of verifying that
these two identities match. 

> 
> Hm.  This discussion reminds me of the OAuth session fixation attack.
> Translating the attack into our environment it would work like this:
> Client X wants to send an e-mail using OpenID authentication.  Client
X
> is tricked into talking to attacker Y.  Attacker opens another channel
> to real server Z and starts authentication, and forwards the requests
> back to Client X.  Client X performs the authentication, which results
> in attacker Y is authenticated as Client X to real server Z.
> 
> However, this attack is pre-empted by requiring the Client X to
validate
> that the server it talks to is a trusted server using TLS server
> certificate validation.  I don't think it will be particulary strong
in
> practice -- SMTP clients rarely have trust anchors configured by the
> users, but at best rely on pre-configured CAs from the software
> manufacturer (which is weak security).  But at least we can claim it
is
> not a protocol weakness.

I agree with you. The attack will fail if the client indeed knows with
whom they should be talking to, have a certain sets of certs
preconfigured, or use a specific trust anchor only. 

I still believe it is important to describe this type of attack in the
document clearly to make sure that system architects and developers
understand the assumptions being made. 

> 
> I could very well be missing your point... thoughts?
> 
> /Simon

Ciao
Hannes
> 
> "Hannes Tschofenig" <[email-masked]> writes:
> 
> > Hi Simon,
> >
> > I noticed that you and Eliot had exchanged some emails about this
> > topic already (and they all ended up in my spam folder). I will have
> > to browse through them. I will also have to read SASL SCRAM to be
sure
> > I understand your concern.
> >
> > However, with the concern you describe it seems that you are more
> > looking into something related to cryptographic bindings, see
> > http://www.springerlink.com/content/8qv4qncf4fk106pg/.
> >
> > I doubt that you will easily get around verifying the server
provided
> > certificate but you could check whether the identities provided at
the
> > different layers match, namely RP_TLS_X and RP_OpenID_Y. Doing this
> > would at least ensure that the end points are the same, which is
what
> > you are verifying when you hash data from both layers together.
> >
> > A separate, but important aspect, is to figure out what are the
> > pre-conditions for a MITM attack to work and whether the threat is
> > high enough to justify a solution.
> >
> > Ciao Hannes
> >
> > -------- Original-Nachricht --------
> >> Datum: Thu, 08 Jul 2010 15:03:31 +0200 Von: Simon Josefsson
> >> <[email-masked]> An: Hannes Tschofenig
> >> <[email-masked]> CC: Eliot Lear <[email-masked]>,
> >> [email-masked] Betreff: Re: OpenID & SASL: Channel Bindings
> >
> >> Hannes Tschofenig <[email-masked]> writes:
> >> 
> >> > Hi all,
> >> > I had a brief chat with Eliot two days ago and we ran into the
> >> > topic of "channel bindings". I thought I should share my opinion
> >> > with you.
> >> > First, I have to say that I find the writeup by Nico in RFC 5056
> >> > hard to understand. I re-read it today and it still confuses me.
I
> >> > also have the history of the EAP work in my head, which (due to
> >> > the name collision) makes everything just more complicated.
> >>  Hi.  Yes, I have also found that document difficult to understand,
> >> and I participated in the discussions around it.  I don't envy
> >> anyone else trying to understand it.
> >> 
> >> > Ignoring what I said in the previous paragraph, let me start
> >> > slightly differently to understand what you guys worry about
> >> > (based on the figure from the draft):
> >>  Let me also say that my answer below is what _I_ worry about: I
don't
> >> know for what purpose Nico would like to see support for channel
> >> bindings.
> >> 
> >> > +-----------+ | | >| Relying | / | Party | // | | //
+-----------+
> >> > // ^ OpenID // +--|--+ // | O| | / S | p| | // A | e| | // S | n|
> >> > | // L | I| | // | D| | </ +--|--+ +------------+ v
> >> >       |            | +----------+ OpenID | OpenID | | Provider
> >> >       | |<--------------->| Client | | | |
> >> >       +------------+ +----------+
> >> > We assume that TLS is used between the client and the relying
> >> > party with server-side autnentication.  The certificate used for
> >> > this purpose will show some identity, let us call it RP_TLS_X.
> >>  Right.
> >> 
> >> > Then, we might have TLS between the Client and the OpenID
provider
> >> > but that largely depends on the authentication mechanism being
> >> > used.
> >>  Yes.  Mentally, I try to ignore what happens outside of the
> >> Client<->RP communication because it is authentication mechanism
> >> specific.  Whether it uses TLS or not is not relevant.  So to me,
> >> the only relevant TLS channel to worry about is the Client<->RP
> >> channel.
> >> 
> >> > Furthermore, we have authentication of the RP to the OP (and vice
> >> > versa) at the OpenID "application layer". The RP will have some
> >> > identity, let us call it RP_OpenID_Y.
> >> > Now, I believe you guys worry about the linkage between the TLS
> >> > channel (used between the client and the RP) and the OpenID
> >> > identity used by the RP.
> >> > Is this correct?
> >>  I'm not sure that is really the same that I worry about.  I worry
> >> about a MITM between Client and RP.  There are two ways to detect
> >> the MITM:
> >> 
> >> 1) Require server certificate validation by the client.  This is
the
> >> traditional solution, but in practice it is quite weak because
> >> clients either trust a gazillion of CAs out there (which is a bad
> >> idea) that easily allows a MITM to acquire a fraudulent certificate
> >> or the end-user manually inspects the certificate and clicks OK (in
> >> practice probably even worse given that end-users can't be trusted
> >> with these decisions in general).  There is no automatic and secure
> >> way for clients to learn the trust anchor used by the server.
> >> 
> >> 2) Both client and RP hashes (or somehow mixes in) the channel
> >> binding data into the authentication process in a way that if the
> >> channel binding data does NOT match, authentication will fail.
> >> 
> >> SASL PLAIN uses approach 1).  SASL SCRAM uses approach 2).  For
> >> SCRAM, achieving 2 is easy because there is a shared secret between
> >> client and server, and each peer can HMAC its channel binding and
> >> the peer can verify the HMAC and then any MITM is detected.
> >> 
> >> I would like to have support for channel bindings in the OpenID
(and
> >> SAML) SASL mechanism because I believe 2) provides stronger
> >> protection than 1).  However, I also realize that given how OpenID
> >> works, it _may_ be impossible without modifying the IdP.  But I
don't
> >> think we have proven that yet.  Maybe we can use the returns_to URL
> >> to store the channel binding data, and allow Client+RP to parse and
> >> validate that.
> >> 
> >> Is this clearer?
> >> 
> >> /Simon

From: "Hannes Tschofenig" <[email-masked]>
Subject: Re: OpenID & SASL: Channel Bindings
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Sun, 11 Jul 2010 11:24:34 +0200

Hi Simon, 

now I read SASL SCRAM and I browsed my way through your prior email
exchange with Eliot. 

SASL SCRAM has a very different motivation for linking the challenge -
response authentication exchange with an underlying TLS (or similar
exchange). 

First, SASL SCRAM provides a lot of options and that's not particularly
useful for security; although this approach is quite fashionable today. 
There are at least the following approaches: 

(1) Challenge Response without any underlying security 
(2) Challenge Response with underlying TLS (without client- and
server-side exchange, such as a anonymous DH exchange)
(3) Challenge Response with TLS including server-side authentication. 

We will not further discuss item #1. 

Now, the assumption for linking the TLS exchange with the SASL
authentication seems to focus on item #2 to ensure that security does
not downgrade to the one of item #1 when an active adversary is present.
The SASL SCRAM specification does not talk about item #3 because it does
not really make sense given that the design could be done entirely
differently if you assume server-side PK-based authentication, i.e. you
can accomplish much better properties if you assume that you can utilize
a PK-based infrastructure. 

Now, the main question is how this translates to our problem. 
The usage of OpenID does not really follow the same patterns. Instead
nobody seems to have a problem with the usage of server-side
authentication using TLS nor do we assume that the client and the
relying party use a shared secret either (which would totally void the
entire OpenID / WebSSO model). Finally, I hope that in the SASL SCRAM
model the client does not talk to a random server it has never met
before (at least the server has to be from the same administrative
domain as the password database). This is, however, the model with
OpenID.

In a nutshell, I don't believe the SASL SCRAM channel binding makes a
lot of sense in our use case unless we change some of the fundamental
assumptions of how OpenID is supposed to work. 

Hence, I would rather go along the road to brainstorming on how to
compare the identities of the two authentication exchanges (only the
RP's identities of course), as I mentioned in my previous mail. Funny
enough even there it is not clear whether we actually want to have the
two identities to match since it would rule out load balancers where the
TLS exchange terminates earlier and the OpenID exchange starts somewhere
in the backend. 

I hope this makes some sense. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Thu, 08 Jul 2010 15:03:31 +0200
> Von: Simon Josefsson <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>
> CC: Eliot Lear <[email-masked]>, [email-masked]
> Betreff: Re: OpenID & SASL: Channel Bindings

> Hannes Tschofenig <[email-masked]> writes:
> 
> > Hi all,
> >
> > I had a brief chat with Eliot two days ago and we ran into the topic
> > of "channel bindings". I thought I should share my opinion with you.
> >
> > First, I have to say that I find the writeup by Nico in RFC 5056
hard
> > to understand. I re-read it today and it still confuses me. I also
> > have the history of the EAP work in my head, which (due to the name
> > collision) makes everything just more complicated.
> 
> Hi.  Yes, I have also found that document difficult to understand, and
I
> participated in the discussions around it.  I don't envy anyone else
> trying to understand it.
> 
> > Ignoring what I said in the previous paragraph, let me start
slightly
> > differently to understand what you guys worry about (based on the
> > figure from the draft):
> 
> Let me also say that my answer below is what _I_ worry about: I don't
> know for what purpose Nico would like to see support for channel
> bindings.
> 
> >
> >                                     +-----------+
> >                                     |           |
> >                                    >|  Relying  |
> >                                   / |  Party    |
> >                                 //  |           |
> >                               //    +-----------+
> >                             //            ^
> >                    OpenID //           +--|--+
> >                         //             | O|  |
> >                        /             S | p|  |
> >                      //              A | e|  |
> >                    //                S | n|  |
> >                  //                  L | I|  |
> >                //                      | D|  |
> >              </                        +--|--+
> >       +------------+                      v
> >       |            |                 +----------+
> >       |  OpenID    |   OpenID        |          |
> >       |  Provider  |<--------------->|  Client  |
> >       |            |                 |          |
> >       +------------+                 +----------+
> >
> > We assume that TLS is used between the client and the relying party
> > with server-side autnentication.  The certificate used for this
> > purpose will show some identity, let us call it RP_TLS_X.
> 
> Right.
> 
> > Then, we might have TLS between the Client and the OpenID provider
but
> > that largely depends on the authentication mechanism being used.
> 
> Yes.  Mentally, I try to ignore what happens outside of the
Client<->RP
> communication because it is authentication mechanism specific.
Whether
> it uses TLS or not is not relevant.  So to me, the only relevant TLS
> channel to worry about is the Client<->RP channel.
> 
> > Furthermore, we have authentication of the RP to the OP (and vice
> > versa) at the OpenID "application layer". The RP will have some
> > identity, let us call it RP_OpenID_Y.
> >
> > Now, I believe you guys worry about the linkage between the TLS
> > channel (used between the client and the RP) and the OpenID identity
> > used by the RP.
> >
> > Is this correct?
> 
> I'm not sure that is really the same that I worry about.  I worry
about
> a MITM between Client and RP.  There are two ways to detect the MITM:
> 
> 1) Require server certificate validation by the client.  This is the
> traditional solution, but in practice it is quite weak because clients
> either trust a gazillion of CAs out there (which is a bad idea) that
> easily allows a MITM to acquire a fraudulent certificate or the
end-user
> manually inspects the certificate and clicks OK (in practice probably
> even worse given that end-users can't be trusted with these decisions
in
> general).  There is no automatic and secure way for clients to learn
the
> trust anchor used by the server.
> 
> 2) Both client and RP hashes (or somehow mixes in) the channel binding
> data into the authentication process in a way that if the channel
> binding data does NOT match, authentication will fail.
> 
> SASL PLAIN uses approach 1).  SASL SCRAM uses approach 2).  For SCRAM,
> achieving 2 is easy because there is a shared secret between client
and
> server, and each peer can HMAC its channel binding and the peer can
> verify the HMAC and then any MITM is detected.
> 
> I would like to have support for channel bindings in the OpenID (and
> SAML) SASL mechanism because I believe 2) provides stronger protection
> than 1).  However, I also realize that given how OpenID works, it
_may_
> be impossible without modifying the IdP.  But I don't think we have
> proven that yet.  Maybe we can use the returns_to URL to store the
> channel binding data, and allow Client+RP to parse and validate that.
> 
> Is this clearer?
> 
> /Simon

From: Simon Josefsson <[email-masked]>
Subject: Re: OpenID & SASL: Channel Bindings
To: "Hannes Tschofenig" <[email-masked]>
Cc: [email-masked],  [email-masked]
Date: Mon, 12 Jul 2010 14:27:09 +0200

Hi Hannes,

I agree with your analysis, which is why I suggested adding the
following section to the document (and Eliot added it for -01):

1.2.  Applicability

   Because this mechanism transports information that should not be
   controlled by an attacker, the OpenID mechanism MUST only be used
   over channels protected by TLS [RFC5246], and the client MUST
   successfully validate the server certificate, or similar integrity
   protected and authenticated channels.

And further:

   The "gs2-cb- flag" MUST be "n" because channel binding is not
   supported by this mechanism.

This puts OpenID-SASL in the (3) case.  Doesn't this solve your concern?

I still haven't ruled out the possibility that we can negotiate channel
binding through OpenID, if that is really is required.  I'll try to
describe one way to do this, so we can all analyze it further.  If
possible, this would support both (2) and (3) approaches, which is more
flexible, but it isn't clear if that flexibility is actually needed.  I
prefer being conservative in adding features, so if it is not needed,
let's not add it, at least not initially.

I'll try to read your other e-mail about matching RP identities.  I'm
not sure I follow that part.

/Simon

"Hannes Tschofenig" <[email-masked]> writes:

> Hi Simon,
>
> now I read SASL SCRAM and I browsed my way through your prior email
> exchange with Eliot.
>
> SASL SCRAM has a very different motivation for linking the challenge -
> response authentication exchange with an underlying TLS (or similar
> exchange).
>
> First, SASL SCRAM provides a lot of options and that's not
> particularly useful for security; although this approach is quite
> fashionable today.  There are at least the following approaches:
>
> (1) Challenge Response without any underlying security (2) Challenge
> Response with underlying TLS (without client- and server-side
> exchange, such as a anonymous DH exchange) (3) Challenge Response with
> TLS including server-side authentication.
>
> We will not further discuss item #1.
>
> Now, the assumption for linking the TLS exchange with the SASL
> authentication seems to focus on item #2 to ensure that security does
> not downgrade to the one of item #1 when an active adversary is
> present. The SASL SCRAM specification does not talk about item #3
> because it does not really make sense given that the design could be
> done entirely differently if you assume server-side PK-based
> authentication, i.e. you can accomplish much better properties if you
> assume that you can utilize a PK-based infrastructure.
>
> Now, the main question is how this translates to our problem.  The
> usage of OpenID does not really follow the same patterns. Instead
> nobody seems to have a problem with the usage of server-side
> authentication using TLS nor do we assume that the client and the
> relying party use a shared secret either (which would totally void the
> entire OpenID / WebSSO model). Finally, I hope that in the SASL SCRAM
> model the client does not talk to a random server it has never met
> before (at least the server has to be from the same administrative
> domain as the password database). This is, however, the model with
> OpenID.
>
> In a nutshell, I don't believe the SASL SCRAM channel binding makes a
> lot of sense in our use case unless we change some of the fundamental
> assumptions of how OpenID is supposed to work.
>
> Hence, I would rather go along the road to brainstorming on how to
> compare the identities of the two authentication exchanges (only the
> RP's identities of course), as I mentioned in my previous mail. Funny
> enough even there it is not clear whether we actually want to have the
> two identities to match since it would rule out load balancers where
> the TLS exchange terminates earlier and the OpenID exchange starts
> somewhere in the backend.
>
> I hope this makes some sense.
>
> Ciao Hannes
>
> -------- Original-Nachricht --------
>> Datum: Thu, 08 Jul 2010 15:03:31 +0200 Von: Simon Josefsson
>> <[email-masked]> An: Hannes Tschofenig
>> <[email-masked]> CC: Eliot Lear <[email-masked]>,
>> [email-masked] Betreff: Re: OpenID & SASL: Channel Bindings
>
>> Hannes Tschofenig <[email-masked]> writes:
>> 
>> > Hi all,
>> > I had a brief chat with Eliot two days ago and we ran into the
>> > topic of "channel bindings". I thought I should share my opinion
>> > with you.
>> > First, I have to say that I find the writeup by Nico in RFC 5056
>> > hard to understand. I re-read it today and it still confuses me. I
>> > also have the history of the EAP work in my head, which (due to
>> > the name collision) makes everything just more complicated.
>>  Hi.  Yes, I have also found that document difficult to understand,
>> and I participated in the discussions around it.  I don't envy
>> anyone else trying to understand it.
>> 
>> > Ignoring what I said in the previous paragraph, let me start
>> > slightly differently to understand what you guys worry about
>> > (based on the figure from the draft):
>>  Let me also say that my answer below is what _I_ worry about: I
don't
>> know for what purpose Nico would like to see support for channel
>> bindings.
>> 
>> > +-----------+ | | >| Relying | / | Party | // | | // +-----------+
>> > // ^ OpenID // +--|--+ // | O| | / S | p| | // A | e| | // S | n|
>> > | // L | I| | // | D| | </ +--|--+ +------------+ v
>> >       |            | +----------+ OpenID | OpenID | | Provider
>> >       | |<--------------->| Client | | | |
>> >       +------------+ +----------+
>> > We assume that TLS is used between the client and the relying
>> > party with server-side autnentication.  The certificate used for
>> > this purpose will show some identity, let us call it RP_TLS_X.
>>  Right.
>> 
>> > Then, we might have TLS between the Client and the OpenID provider
>> > but that largely depends on the authentication mechanism being
>> > used.
>>  Yes.  Mentally, I try to ignore what happens outside of the
>> Client<->RP communication because it is authentication mechanism
>> specific.  Whether it uses TLS or not is not relevant.  So to me,
>> the only relevant TLS channel to worry about is the Client<->RP
>> channel.
>> 
>> > Furthermore, we have authentication of the RP to the OP (and vice
>> > versa) at the OpenID "application layer". The RP will have some
>> > identity, let us call it RP_OpenID_Y.
>> > Now, I believe you guys worry about the linkage between the TLS
>> > channel (used between the client and the RP) and the OpenID
>> > identity used by the RP.
>> > Is this correct?
>>  I'm not sure that is really the same that I worry about.  I worry
>> about a MITM between Client and RP.  There are two ways to detect
>> the MITM:
>> 
>> 1) Require server certificate validation by the client.  This is the
>> traditional solution, but in practice it is quite weak because
>> clients either trust a gazillion of CAs out there (which is a bad
>> idea) that easily allows a MITM to acquire a fraudulent certificate
>> or the end-user manually inspects the certificate and clicks OK (in
>> practice probably even worse given that end-users can't be trusted
>> with these decisions in general).  There is no automatic and secure
>> way for clients to learn the trust anchor used by the server.
>> 
>> 2) Both client and RP hashes (or somehow mixes in) the channel
>> binding data into the authentication process in a way that if the
>> channel binding data does NOT match, authentication will fail.
>> 
>> SASL PLAIN uses approach 1).  SASL SCRAM uses approach 2).  For
>> SCRAM, achieving 2 is easy because there is a shared secret between
>> client and server, and each peer can HMAC its channel binding and
>> the peer can verify the HMAC and then any MITM is detected.
>> 
>> I would like to have support for channel bindings in the OpenID (and
>> SAML) SASL mechanism because I believe 2) provides stronger
>> protection than 1).  However, I also realize that given how OpenID
>> works, it _may_ be impossible without modifying the IdP.  But I don't
>> think we have proven that yet.  Maybe we can use the returns_to URL
>> to store the channel binding data, and allow Client+RP to parse and
>> validate that.
>> 
>> Is this clearer?
>> 
>> /Simon

From: Eliot Lear <[email-masked]>
Subject: Re: OpenID & SASL: Channel Bindings
To: Simon Josefsson <[email-masked]>
CC: Hannes Tschofenig <[email-masked]>, [email-masked]
Date: Mon, 12 Jul 2010 14:37:26 +0200

 Simon, Hannes,

Excellent discussion.  I think we're all in agreement.  There is now a
-02 fyi which corrects one missed OPENID2.0.  I would like to propose
meeting Sunday night.  Does this work for everyone?

Eliot

On 7/12/10 2:27 PM, Simon Josefsson wrote:
> Hi Hannes,
>
> I agree with your analysis, which is why I suggested adding the
> following section to the document (and Eliot added it for -01):
>
> 1.2.  Applicability
>
>    Because this mechanism transports information that should not be
>    controlled by an attacker, the OpenID mechanism MUST only be used
>    over channels protected by TLS [RFC5246], and the client MUST
>    successfully validate the server certificate, or similar integrity
>    protected and authenticated channels.
>
> And further:
>
>    The "gs2-cb- flag" MUST be "n" because channel binding is not
>    supported by this mechanism.
>
> This puts OpenID-SASL in the (3) case.  Doesn't this solve your
concern?
>
> I still haven't ruled out the possibility that we can negotiate
channel
> binding through OpenID, if that is really is required.  I'll try to
> describe one way to do this, so we can all analyze it further.  If
> possible, this would support both (2) and (3) approaches, which is
more
> flexible, but it isn't clear if that flexibility is actually needed.
I
> prefer being conservative in adding features, so if it is not needed,
> let's not add it, at least not initially.
>
> I'll try to read your other e-mail about matching RP identities.  I'm
> not sure I follow that part.
>
> /Simon
>
> "Hannes Tschofenig" <[email-masked]> writes:
>
>> Hi Simon,
>>
>> now I read SASL SCRAM and I browsed my way through your prior email
>> exchange with Eliot.
>>
>> SASL SCRAM has a very different motivation for linking the challenge
-
>> response authentication exchange with an underlying TLS (or similar
>> exchange).
>>
>> First, SASL SCRAM provides a lot of options and that's not
>> particularly useful for security; although this approach is quite
>> fashionable today.  There are at least the following approaches:
>>
>> (1) Challenge Response without any underlying security (2) Challenge
>> Response with underlying TLS (without client- and server-side
>> exchange, such as a anonymous DH exchange) (3) Challenge Response
with
>> TLS including server-side authentication.
>>
>> We will not further discuss item #1.
>>
>> Now, the assumption for linking the TLS exchange with the SASL
>> authentication seems to focus on item #2 to ensure that security does
>> not downgrade to the one of item #1 when an active adversary is
>> present. The SASL SCRAM specification does not talk about item #3
>> because it does not really make sense given that the design could be
>> done entirely differently if you assume server-side PK-based
>> authentication, i.e. you can accomplish much better properties if you
>> assume that you can utilize a PK-based infrastructure.
>>
>> Now, the main question is how this translates to our problem.  The
>> usage of OpenID does not really follow the same patterns. Instead
>> nobody seems to have a problem with the usage of server-side
>> authentication using TLS nor do we assume that the client and the
>> relying party use a shared secret either (which would totally void
the
>> entire OpenID / WebSSO model). Finally, I hope that in the SASL SCRAM
>> model the client does not talk to a random server it has never met
>> before (at least the server has to be from the same administrative
>> domain as the password database). This is, however, the model with
>> OpenID.
>>
>> In a nutshell, I don't believe the SASL SCRAM channel binding makes a
>> lot of sense in our use case unless we change some of the fundamental
>> assumptions of how OpenID is supposed to work.
>>
>> Hence, I would rather go along the road to brainstorming on how to
>> compare the identities of the two authentication exchanges (only the
>> RP's identities of course), as I mentioned in my previous mail. Funny
>> enough even there it is not clear whether we actually want to have
the
>> two identities to match since it would rule out load balancers where
>> the TLS exchange terminates earlier and the OpenID exchange starts
>> somewhere in the backend.
>>
>> I hope this makes some sense.
>>
>> Ciao Hannes
>>
>> -------- Original-Nachricht --------
>>> Datum: Thu, 08 Jul 2010 15:03:31 +0200 Von: Simon Josefsson
>>> <[email-masked]> An: Hannes Tschofenig
>>> <[email-masked]> CC: Eliot Lear <[email-masked]>,
>>> [email-masked] Betreff: Re: OpenID & SASL: Channel Bindings
>>> Hannes Tschofenig <[email-masked]> writes:
>>>
>>>> Hi all,
>>>> I had a brief chat with Eliot two days ago and we ran into the
>>>> topic of "channel bindings". I thought I should share my opinion
>>>> with you.
>>>> First, I have to say that I find the writeup by Nico in RFC 5056
>>>> hard to understand. I re-read it today and it still confuses me. I
>>>> also have the history of the EAP work in my head, which (due to
>>>> the name collision) makes everything just more complicated.
>>>  Hi.  Yes, I have also found that document difficult to understand,
>>> and I participated in the discussions around it.  I don't envy
>>> anyone else trying to understand it.
>>>
>>>> Ignoring what I said in the previous paragraph, let me start
>>>> slightly differently to understand what you guys worry about
>>>> (based on the figure from the draft):
>>>  Let me also say that my answer below is what _I_ worry about: I
don't
>>> know for what purpose Nico would like to see support for channel
>>> bindings.
>>>
>>>> +-----------+ | | >| Relying | / | Party | // | | // +-----------+
>>>> // ^ OpenID // +--|--+ // | O| | / S | p| | // A | e| | // S | n|
>>>> | // L | I| | // | D| | </ +--|--+ +------------+ v
>>>>       |            | +----------+ OpenID | OpenID | | Provider
>>>>       | |<--------------->| Client | | | |
>>>>       +------------+ +----------+
>>>> We assume that TLS is used between the client and the relying
>>>> party with server-side autnentication.  The certificate used for
>>>> this purpose will show some identity, let us call it RP_TLS_X.
>>>  Right.
>>>
>>>> Then, we might have TLS between the Client and the OpenID provider
>>>> but that largely depends on the authentication mechanism being
>>>> used.
>>>  Yes.  Mentally, I try to ignore what happens outside of the
>>> Client<->RP communication because it is authentication mechanism
>>> specific.  Whether it uses TLS or not is not relevant.  So to me,
>>> the only relevant TLS channel to worry about is the Client<->RP
>>> channel.
>>>
>>>> Furthermore, we have authentication of the RP to the OP (and vice
>>>> versa) at the OpenID "application layer". The RP will have some
>>>> identity, let us call it RP_OpenID_Y.
>>>> Now, I believe you guys worry about the linkage between the TLS
>>>> channel (used between the client and the RP) and the OpenID
>>>> identity used by the RP.
>>>> Is this correct?
>>>  I'm not sure that is really the same that I worry about.  I worry
>>> about a MITM between Client and RP.  There are two ways to detect
>>> the MITM:
>>>
>>> 1) Require server certificate validation by the client.  This is the
>>> traditional solution, but in practice it is quite weak because
>>> clients either trust a gazillion of CAs out there (which is a bad
>>> idea) that easily allows a MITM to acquire a fraudulent certificate
>>> or the end-user manually inspects the certificate and clicks OK (in
>>> practice probably even worse given that end-users can't be trusted
>>> with these decisions in general).  There is no automatic and secure
>>> way for clients to learn the trust anchor used by the server.
>>>
>>> 2) Both client and RP hashes (or somehow mixes in) the channel
>>> binding data into the authentication process in a way that if the
>>> channel binding data does NOT match, authentication will fail.
>>>
>>> SASL PLAIN uses approach 1).  SASL SCRAM uses approach 2).  For
>>> SCRAM, achieving 2 is easy because there is a shared secret between
>>> client and server, and each peer can HMAC its channel binding and
>>> the peer can verify the HMAC and then any MITM is detected.
>>>
>>> I would like to have support for channel bindings in the OpenID (and
>>> SAML) SASL mechanism because I believe 2) provides stronger
>>> protection than 1).  However, I also realize that given how OpenID
>>> works, it _may_ be impossible without modifying the IdP.  But I
don't
>>> think we have proven that yet.  Maybe we can use the returns_to URL
>>> to store the channel binding data, and allow Client+RP to parse and
>>> validate that.
>>>
>>> Is this clearer?
>>>
>>> /Simon

From: "Hannes Tschofenig" <[email-masked]>
Subject: Re: OpenID & SASL: Channel Bindings
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Tue, 20 Jul 2010 11:45:23 +0200

This text is good for me. 

-------- Original-Nachricht --------
> Datum: Mon, 12 Jul 2010 14:27:09 +0200
> Von: Simon Josefsson <[email-masked]>
> An: "Hannes Tschofenig" <[email-masked]>
> CC: [email-masked], [email-masked]
> Betreff: Re: OpenID & SASL: Channel Bindings

> Hi Hannes,
> 
> I agree with your analysis, which is why I suggested adding the
> following section to the document (and Eliot added it for -01):
> 
> 1.2.  Applicability
> 
>    Because this mechanism transports information that should not be
>    controlled by an attacker, the OpenID mechanism MUST only be used
>    over channels protected by TLS [RFC5246], and the client MUST
>    successfully validate the server certificate, or similar integrity
>    protected and authenticated channels.
> 
> And further:
> 
>    The "gs2-cb- flag" MUST be "n" because channel binding is not
>    supported by this mechanism.
> 
> This puts OpenID-SASL in the (3) case.  Doesn't this solve your
concern?
> 
> I still haven't ruled out the possibility that we can negotiate
channel
> binding through OpenID, if that is really is required.  I'll try to
> describe one way to do this, so we can all analyze it further.  If
> possible, this would support both (2) and (3) approaches, which is
more
> flexible, but it isn't clear if that flexibility is actually needed.
I
> prefer being conservative in adding features, so if it is not needed,
> let's not add it, at least not initially.
> 
> I'll try to read your other e-mail about matching RP identities.  I'm
> not sure I follow that part.
> 
> /Simon
> 
> "Hannes Tschofenig" <[email-masked]> writes:
> 
> > Hi Simon,
> >
> > now I read SASL SCRAM and I browsed my way through your prior email
> > exchange with Eliot.
> >
> > SASL SCRAM has a very different motivation for linking the challenge
-
> > response authentication exchange with an underlying TLS (or similar
> > exchange).
> >
> > First, SASL SCRAM provides a lot of options and that's not
> > particularly useful for security; although this approach is quite
> > fashionable today.  There are at least the following approaches:
> >
> > (1) Challenge Response without any underlying security (2) Challenge
> > Response with underlying TLS (without client- and server-side
> > exchange, such as a anonymous DH exchange) (3) Challenge Response
with
> > TLS including server-side authentication.
> >
> > We will not further discuss item #1.
> >
> > Now, the assumption for linking the TLS exchange with the SASL
> > authentication seems to focus on item #2 to ensure that security
does
> > not downgrade to the one of item #1 when an active adversary is
> > present. The SASL SCRAM specification does not talk about item #3
> > because it does not really make sense given that the design could be
> > done entirely differently if you assume server-side PK-based
> > authentication, i.e. you can accomplish much better properties if
you
> > assume that you can utilize a PK-based infrastructure.
> >
> > Now, the main question is how this translates to our problem.  The
> > usage of OpenID does not really follow the same patterns. Instead
> > nobody seems to have a problem with the usage of server-side
> > authentication using TLS nor do we assume that the client and the
> > relying party use a shared secret either (which would totally void
the
> > entire OpenID / WebSSO model). Finally, I hope that in the SASL
SCRAM
> > model the client does not talk to a random server it has never met
> > before (at least the server has to be from the same administrative
> > domain as the password database). This is, however, the model with
> > OpenID.
> >
> > In a nutshell, I don't believe the SASL SCRAM channel binding makes
a
> > lot of sense in our use case unless we change some of the
fundamental
> > assumptions of how OpenID is supposed to work.
> >
> > Hence, I would rather go along the road to brainstorming on how to
> > compare the identities of the two authentication exchanges (only the
> > RP's identities of course), as I mentioned in my previous mail.
Funny
> > enough even there it is not clear whether we actually want to have
the
> > two identities to match since it would rule out load balancers where
> > the TLS exchange terminates earlier and the OpenID exchange starts
> > somewhere in the backend.
> >
> > I hope this makes some sense.
> >
> > Ciao Hannes
> >
> > -------- Original-Nachricht --------
> >> Datum: Thu, 08 Jul 2010 15:03:31 +0200 Von: Simon Josefsson
> >> <[email-masked]> An: Hannes Tschofenig
> >> <[email-masked]> CC: Eliot Lear <[email-masked]>,
> >> [email-masked] Betreff: Re: OpenID & SASL: Channel Bindings
> >
> >> Hannes Tschofenig <[email-masked]> writes:
> >> 
> >> > Hi all,
> >> > I had a brief chat with Eliot two days ago and we ran into the
> >> > topic of "channel bindings". I thought I should share my opinion
> >> > with you.
> >> > First, I have to say that I find the writeup by Nico in RFC 5056
> >> > hard to understand. I re-read it today and it still confuses me.
I
> >> > also have the history of the EAP work in my head, which (due to
> >> > the name collision) makes everything just more complicated.
> >>  Hi.  Yes, I have also found that document difficult to understand,
> >> and I participated in the discussions around it.  I don't envy
> >> anyone else trying to understand it.
> >> 
> >> > Ignoring what I said in the previous paragraph, let me start
> >> > slightly differently to understand what you guys worry about
> >> > (based on the figure from the draft):
> >>  Let me also say that my answer below is what _I_ worry about: I
don't
> >> know for what purpose Nico would like to see support for channel
> >> bindings.
> >> 
> >> > +-----------+ | | >| Relying | / | Party | // | | //
+-----------+
> >> > // ^ OpenID // +--|--+ // | O| | / S | p| | // A | e| | // S | n|
> >> > | // L | I| | // | D| | </ +--|--+ +------------+ v
> >> >       |            | +----------+ OpenID | OpenID | | Provider
> >> >       | |<--------------->| Client | | | |
> >> >       +------------+ +----------+
> >> > We assume that TLS is used between the client and the relying
> >> > party with server-side autnentication.  The certificate used for
> >> > this purpose will show some identity, let us call it RP_TLS_X.
> >>  Right.
> >> 
> >> > Then, we might have TLS between the Client and the OpenID
provider
> >> > but that largely depends on the authentication mechanism being
> >> > used.
> >>  Yes.  Mentally, I try to ignore what happens outside of the
> >> Client<->RP communication because it is authentication mechanism
> >> specific.  Whether it uses TLS or not is not relevant.  So to me,
> >> the only relevant TLS channel to worry about is the Client<->RP
> >> channel.
> >> 
> >> > Furthermore, we have authentication of the RP to the OP (and vice
> >> > versa) at the OpenID "application layer". The RP will have some
> >> > identity, let us call it RP_OpenID_Y.
> >> > Now, I believe you guys worry about the linkage between the TLS
> >> > channel (used between the client and the RP) and the OpenID
> >> > identity used by the RP.
> >> > Is this correct?
> >>  I'm not sure that is really the same that I worry about.  I worry
> >> about a MITM between Client and RP.  There are two ways to detect
> >> the MITM:
> >> 
> >> 1) Require server certificate validation by the client.  This is
the
> >> traditional solution, but in practice it is quite weak because
> >> clients either trust a gazillion of CAs out there (which is a bad
> >> idea) that easily allows a MITM to acquire a fraudulent certificate
> >> or the end-user manually inspects the certificate and clicks OK (in
> >> practice probably even worse given that end-users can't be trusted
> >> with these decisions in general).  There is no automatic and secure
> >> way for clients to learn the trust anchor used by the server.
> >> 
> >> 2) Both client and RP hashes (or somehow mixes in) the channel
> >> binding data into the authentication process in a way that if the
> >> channel binding data does NOT match, authentication will fail.
> >> 
> >> SASL PLAIN uses approach 1).  SASL SCRAM uses approach 2).  For
> >> SCRAM, achieving 2 is easy because there is a shared secret between
> >> client and server, and each peer can HMAC its channel binding and
> >> the peer can verify the HMAC and then any MITM is detected.
> >> 
> >> I would like to have support for channel bindings in the OpenID
(and
> >> SAML) SASL mechanism because I believe 2) provides stronger
> >> protection than 1).  However, I also realize that given how OpenID
> >> works, it _may_ be impossible without modifying the IdP.  But I
don't
> >> think we have proven that yet.  Maybe we can use the returns_to URL
> >> to store the channel binding data, and allow Client+RP to parse and
> >> validate that.
> >> 
> >> Is this clearer?
> >> 
> >> /Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 16 Aug 2010 10:09:24 -0500

> collision) makes everything just more complicated.

Certainly the EAP terminology collision doesn't help.  You do have to
understand a littled bit about the GSS-API to understand RFC5056, even
though RFC5056 was written to be more generic than that.  Specifically
you have to understand that the only participants that matter for
RFC5056 are the initiator (client) and acceptor (server) -- any
infrastructure services are abstrated out.

You seem to be confused about what "application layer" means in the
RFC5056 context.  If you understand that only the client<->server
communications are in scope, then you can see that "application layer"
refers to "the layer above the secure channel" -- in this case, "the
layer above HTTPS / TLS".  See below.

> differently to understand what you guys worry about (based on the

The question is: does OpenID rely on TLS for authenticating the RP to
the client?  If so then channel binding will be irrelevant to you,
unless you change OpenID to separately authenticate the server.

Now, from the above picture I would think that the OpenID Provider
certainly can authenticate the RP and then tell the client that the RP
is authenticated (either directly or via the RP).

BTW, "relying party" is a very bad term to use here because the client
can be a relying party too (if it has to validate the server's TLS
cert).  In a PKIX sense, to me, "relying party" is any party that
validates certificates.  Whereas in the above figure you're using
"relying party" in the sense of "party that relies on assertions made
by an IdP".

I'd go further: the fact that you use "relying party" to refer to the
server tells me that there may be a fundamental problem with OpenID:
that it concerns itself only with authenticating users to services, but
not services to users.  But services have to be authenticated to users!

> that largely depends on the authentication mechanism being used.

Sure.  This part is not relevant.  As I explained above, RFC5056
concerns itself only with the client<->server interaction.  The security
of client<->infrastructure and server<->infrastructure communications is
outside the scopre of RFC5056, though they are very much relevant to the
security analysis of the whole system, of course.

> at the OpenID "application layer". The RP will have some identity, let

Ah, I see where RFC5056 has you confused.  The only "application layer"
that is relevant here is between the client and the server.

> (used between the client and the RP) and the OpenID identity used by the

Yes, that is correct.

Imagine that the RP is using a self-signed certificate.  Or that the RP
doesn't even have a certificate for use in TLS and therefore negotiates
anonymous DH cipher suites only.  With channel binding we can still make
sure that there is no MITM.

Now, suppose you say "but the RP uses the same certificate to
authenticate itself to the client in TLS as it does to authenticate
itself to the OpenID Provider" [*].  Fair enough, but, the OpenID
Provider can do what is variously called "TLS pinning", "leap-of-faith",
... -- it can keep a table mapping service names to certificates, and
thus provide somewhat stronger authentication than the commercial TLS
PKI can.  Or perhaps the OpenID provider will have a trust relationship
with the RP based on something other than the commercial TLS PKI, and
then it can simply "know" the RP's cert(s).

So you see, channel binding can add value above and beyond that which is
added by the commercial TLS PKI.

Nico

[*] Ignoring, for now, any key hygiene issues.  Most server certs for
    use in TLS are meant for encryption, for RSA key transport.  While
    in all likelihood the server would authenticate itself to the
    provider using an RSA signature.  Since one should not sign and
    encrypt with the same public key pair... presumably the server would
    have different PKI credentials for these two purposes.

---

From: "Scott Cantor" <[email-masked]>
Date: Mon, 16 Aug 2010 11:25:14 -0400

> unless you change OpenID to separately authenticate the server.

Cookie/redirect Web SSO mechanisms designed around a browser (let's ignore
SPNEGO) are essentially incapable of this. In particular, the authentication
of the RP to the client via TLS is not "in scope" of the SSO protocol itself
and is not leveraged, it's merely assumed as a way of avoiding the problem.

The protocol can (SAML does, OpenID does not, mostly) expect the IdP to
provide some protection by validating response URLs, but the actual proof
that the client is visiting the right URL is treated as a TLS problem, not
something the IdP/OP gets involved with.

(This is why I'm interested in the concept of CB, per last weekend's
discussion. But you can't do it with a browser.)

> > at the OpenID "application layer". The RP will have some identity, let

That's news to me (so I'd like to clarify if I'm misled on that). SAML does,
but I was under the impression the only such authentication expected in
OpenID is some simple whitelisting of URLs. In particular, I thought the
whole point was to avoid credentialing RPs.
 
(Nothing to do with the topic, though, just curious.)

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 16 Aug 2010 12:06:14 -0500

> discussion. But you can't do it with a browser.)

Well, maybe browsers today can't do it.

In any case what browsers can do and what non-browsers can do are
different things.  We shouldn't condemn the latter to the limitations of
the former; hopefully the former can catch up to the latter.  (I'm sure
you agree, but I'm stating this for the benefit of others.)

> (Nothing to do with the topic, though, just curious.)

I could see the OpenID provider using TLS client certs to authenticate
the server...  Yes, it'd still be the commercial TLS PKI, but the OpenID
is in a better position to confirm keys off-line or to do leap-of-faith.

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Mon, 16 Aug 2010 13:21:52 -0400

> Well, maybe browsers today can't do it.

That's all I meant.

> you agree, but I'm stating this for the benefit of others.)

Yes, but I also think (but couldn't say for sure) that tying the SASL
mechanism to a browser presents fairly similar constraints. This is exactly
why I'm trying to insist that at least for SAML, there be a completely
non-browser mechanism available and not only the original proposal. For
OpenID there is no choice, because OpenID has no ECP equivalent to leverage.

> is in a better position to confirm keys off-line or to do leap-of-faith.

I'm not asking about what's theoretically possible in such SSO protocols,
but what the OpenID protocol is defined to be. Believe it or not, the lack
of such a step is part of its raison d'etre.

-- Scott

---

From: "Scott Cantor" <[email-masked]>
Date: Mon, 16 Aug 2010 13:24:32 -0400

> Well, maybe browsers today can't do it.

BTW, it might be apropos to note that the name "Moonshot" in the Moonshot
proposal comes from a statement I made on a list that *if* you're going to
change the client (that is, change the browser), and your solution is
predilected on getting browser and/or OS vendors to actually move the ball,
there's little point in taking halfway steps. Design a better solution and
build it, i.e. shoot for the moon.

-- Scott

---

From: Klaas Wierenga <[email-masked]>
Date: Mon, 16 Aug 2010 19:36:54 +0200

> non-browser mechanism available and not only the original proposal. For

for the record, I support that, and it is the reason why I asked Scott 
to write it down. I'd like to see an ECP mechanism get standardized and 
deployed.

> OpenID there is no choice, because OpenID has no ECP equivalent to leverage.

I believe OpenID has limited applicability, for low-value (for whatever 
metric of value) transactions in the browser context, the SASL method 
should not make this worse, but will also not make it any better.

> of such a step is part of its raison d'etre.

Klaas

---

From: "Scott Cantor" <[email-masked]>
Date: Mon, 16 Aug 2010 13:44:49 -0400

> to write it down. I'd like to see an ECP mechanism get standardized and

Which I appreciate. ;-)

> should not make this worse, but will also not make it any better.

I don't want to get into the applicability discussion, because in my
experience, "lightweight" reinvention does not historically stay in the box
that its originators might think it should. I'm just looking purely at the
technical side. To the extent that the technical side is squishy ("some
people implement it this way, even though the spec doesn't really define
that"), that's its own indictment.

-- Scott

---

From: Klaas Wierenga <[email-masked]>
Date: Mon, 16 Aug 2010 20:08:15 +0200

> that"), that's its own indictment.

sure, what I was trying to say is that for a certain use you need 
certain security properties. Usually when the scope creeps the technical 
side changes significantly (is LDAPv3 any more lightweight than DAP?). I 
find it for example telling that the OAuth folks are now talking about 
transporting SAML tokens. OpenID as it stands now doesn't satisfy the 
security constraints of the applications I care about, and even though I 
am not at all convinved that they will ever, I don't rule that out 
beforehand either. But we should not spend too much effort on making 1 
link very strong without working on the rest of the chain.

Klaas

---

From: "Scott Cantor" <[email-masked]>
Date: Mon, 16 Aug 2010 14:17:10 -0400

> OpenID as it stands now doesn't satisfy the

Yeah, the problem I was trying to highlight is that usually people say "we
don't need to fix that, because this isn't meant for applications that care
about that problem". Until inevitably people decide that because it's
simpler it must be better, so it needs to be shoehorned in, and oh well, we
still can't solve that problem, so let's make sure the policies get
rewritten to let us ignore it.

Maybe I've been stuck in too many disfunctional organizations, but policy
where I am has always been "what we have to allow so our chosen solution
will work".

-- Scott

---

From: Josh Howlett <[email-masked]>
Date: Mon, 16 Aug 2010 19:02:03 +0000

Klaas wrote:
> I find it for example telling that the OAuth folks are now talking about
> transporting SAML tokens.

+1

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: Klaas Wierenga <[email-masked]>
Date: Mon, 16 Aug 2010 21:27:20 +0200

Sent from my iPad

> where I am has always been "what we have to allow so our chosen solution

No, that is a fair concern unfortunately

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Aug 2010 11:56:36 -0500

> of such a step is part of its raison d'etre.

Given the figure and explanation given by Hannes I am willing to believe
that OpenID can provide mutual authentication and channel binding in a
manner not unlike the one you've sketched for SAML ECP.  The result
might involve IdPs doing leap-of-faith learning of servers' certs, and
so might be weak, but likely still usable.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Aug 2010 12:33:23 -0500

> that OpenID can provide mutual authentication and channel binding in a

s/can/could eventually/