Subject: Re: [dix] Google Account Authorization - slightly off topic

From: "Ben Laurie" <[email-masked]>
Date: Mon, 3 Jul 2006 14:41:50 +0100

On 6/29/06, Dick Hardt <[email-masked]> wrote:
> Google rolled out some some APIs[1] to make it easier for rich clients
> [2] and websites[3] to act on behalf of a Google user. Of course this
> deepens the identity silo that is building at Google. [3] looks like
> some concepts that ekr has been talking about.
>
> Ben: hate to put you on the spot, but is Google looking to
> participate in WAE?

I will be at the WAE BoF, so, to that extent, yes. Google is certainly
interested in (some of) the problems WAE may work on.

> [1] http://code.google.com/apis/accounts/Authentication.html
> [2] http://code.google.com/apis/accounts/AuthForInstalledApps.html
> [3] http://code.google.com/apis/accounts/AuthForWebApps.html
>
>
> _______________________________________________
> dix mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dix
>

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

---

From: "Ben Laurie" <[email-masked]>
Date: Mon, 3 Jul 2006 14:46:57 +0100

On 6/29/06, Sam Hartman <[email-masked]> wrote:
> Hi.
>
> First, I'd like to thank you for this excellent starting point for the
> discussion.  I do have a few comments, but this is a great taxonomy.
>
>
>
>                              Requirements
>
>   2. Hijack-Resistant Authentication (HRA)
>   An authentication system in which credentials which are bound to
>   protocol messages in such a way that attacker who observes the
>   credentials can't use them to authenticate messages of their
>   choice. The rationale for this feature is to make cut-and-paste
>   attacks difficult.
>
>
> I think this description and the subsequent discussion in
> transporting/binding credentials has some concepts I'd like to
> distinguish muddled together.
>
> Some schemes will provide integrity: a man in the middle can observe
> the conversation but cannot modify the content of the request or
> response.
>
> Some schemes will provide confidentiality even given the practical
> difficulties with server certificate validation.
>
> I argue in section 4.5 and 5 of version 01 of my phishing requirements
> draft that providing confidentiality of the resulting page is
> important even given these practical server certificate issues.  So,
> I'd like to ask you to add that as a potential requirement I might want so I can ask for it.
> Also, let's be careful to distinguish  this from HRA.
>
>
> You don't seem to have a requirement that corresponds to section 4.6
> of 01 of my phishing requirements draft.  This was one of the issues
> muddled into the confusing mutual authentication section in 00 of my
> draft.  I contend that if there are a small number of RPs that by
> policy should be allowed to accept a given identity,there is a
> security benefit in restricting the identity to only those RPs.  In
> particular, if a user successfully authenticates the user knows that
> because their identity was successfully accepted, they have
> authenticated to one of the valid RPs.  I'd be happy to discuss
> specific customer deployments where this will be useful with you
> off-list.  I understand based on your review of my 00 draft that you
> don't like this requirement.  I still think it reasonable to discuss.
>
>
>
>                       TLS Client AUthentication
>
> Your taxonomy assumes that TLS is a valid approach to client
> authentication.  As I understand HTTP, that is only true assuming
> there are no proxies between the user and the RP.

HTTP proxies support the CONNECT method for this (all they do is copy
the raw connection data in both directions). Note that if proxies
didn't do this, then server authentication would also be impossible.

> We could extend HTTP to allow a proxy to assert authentication
> information it received via TLS to the next hop.  It might be possible
> but would be more challenging to extend HTTP so that a client could
> give a proxy credentials to use for TLS client authentication outbound
> from that proxy.  I think these issues are important to consider when
> comparing how credentials and authentication are transported.
> (Personally, I wish we could just ignore the whole issue of proxies.
> I don't think that will be acceptable to the market though.)
>
>
>
>                  Transporting and Binding Credentials
>
>
>   An additional issue is hijacking: without cryptographic
>   binding, an attacker who observes a request can make future
>   requests in the name of the user via a cut-and-paste attack
>   (remember, the token is bearer). If you take the threat of
>   this type of attack seriously, you need to run the traffic
>   over SSL/TLS. [1]
>
>
>   [1] Note that if you're worried about this class of attack, you need
>   *every* PDU to be cryptographically bound to the credential with
>   all designs. If, for instance, you use cert-based auth but then
>   transition to cookies over HTTP for state management, there's a
>   cut-and-paste attack there.
>
>
> I think the primary paragraph is misleading.  We've started from an
> assumption that there are practical problems that prevent server certificates from being validated.  Given this assumption I don't understand how TLS actually gives us protection against the hijacking.
>
> I also think the footnote ignores an important deployment model.  I
>  may be concerned about whether I have reached the right RP while not
>  concerned about network level hijacking.  So I'm not at all convinced
>  that you always need to protect every exchange if you are concerned
>  about hijacking in some situations.
>
> Thanks again for your excellent work and for your consideration of my
> comments.
>
> --Sam
>
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
>

---

From: "Ben Laurie" <[email-masked]>
Date: Mon, 3 Jul 2006 14:50:46 +0100

On 6/27/06, [email-masked] <[email-masked]> wrote:
>
>
> I doubt it will be possible to use exactly the same methods for HTTP, XMPP,
> SMTP and IMAP.  The latter three (XMPP, SMTP and IMAP) are session based,
> and might require authentication/authorization only once during a session.
> HTTP is stateless (at least in general), so some thought needs to be given
> to extending the auth across multiple requests.
>
>  A method for HTTP will need to consider potential performance issues,
> replay protection, and possible tie-in with other available session state
> (such as a TLS channel), among other things.  The others can generally get
> away with a on-time verification step per session.
>
>
>  It may be possible to share portions of the mechanism.  In fact, TLS/SSL
> with client authentication supports all 4 protocols.  However it seems to be
> rejected because of other issues: PKI lifecycles, physical portability of
> the key, trust management, etc.

Assuming TLS is all about X.509 is completely missing the point. TLS
supports several other authentication mechanisms, such as pre-shared
secrets or Kerberos. There's nothing to stop us defining some new ones
if we need them.

>
>  Terry Hayes
>  AOL LLC
>
>
>  -----Original Message-----
>  From: [email-masked]
>  To: [email-masked]
>  Cc: [email-masked]
>  Sent: Tue, 27 Jun 2006 9:57 AM
>  Subject: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web
> authentication enhancements)
>
>
>
> Ben Laurie wrote: >> >> - Does the mechanism use or extend currently
> deployed web >> authentication mechanisms (client side and server side)? If
> not, why >> not? > > No - because if you use web authentication, then it
> will not work for > protocols that are not HTTP based - XMPP and IMAP are
> obvious examples > that spring to mind. I'm not sure I'd go so far as No,
> but the mechanism or an analog must be easily ported to other application
> protocols such as XMPP, SMTP, or IMAP. I would think an existence proof of 2
> (one being HTTP; the other being IMAP) would be a very useful thing for any
> WG. Eliot ______________________________
> _________________ Ietf-http-auth mailing list
>  ________________________________
>  Check out AOL.com today. Breaking news, video search, pictures, email and
> IM. All on demand. Always Free.
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Jul 2006 07:19:41 -0700

> discussion.  I do have a few comments, but this is a great taxonomy.

Thanks. Sorry about the slow response here but I missed this message.

> difficulties with server certificate validation.

Yes, I agree that these are separate services. I agree that
confidentiality of information carried in the transaction important,
but it's not in and of itself an *authentication* goal (though it may
be used in the service of one if, for instance, the tokens used
for authentication are bearer, like cookies.)

> I argue in section 4.5 and 5 of version 01 of my phishing
> requirements draft that providing confidentiality of the resulting
> page is important even given these practical server certificate
> issues.  So, I'd like to ask you to add that as a potential
> requirement I might want so I can ask for it.

I'm not sure this is applicable, since I'm not really maintaining
a document here. That was just a note to the list.

> don't like this requirement.  I still think it reasonable to discuss.

I just forgot this one. My bad. 

That said, I think there are actually two security issues surrounding this:

1. Having the IdP perform some kind of secondary check on the identity
   of the RP.
2. Allowing the IdP to limit the use of credentials to selected RPs.

These sound like the same thing but they're strictly speaking not.
For example, consider a case where the IdP wants to charge RPs for
access to their credentials. In order to do this, they encrypt the
credentials with a fixed key that they send to subscribing
RPs <insert suitable DRM, rollover, etc. here>. This doesn't provide
any assurance to the user unless the RP demonstrates knowledge
of the credentials. The RP might just choose to pretend it had
authenticated the user, if, for instance, it wants to induce
the user to give up personal information.

> authentication. 

I'm not making a judgement about whether it's valid or not. I'm
saying it's been proposed. It has.

> As I understand HTTP, that is only true assuming

no trusted proxies, technically speaking. TLS accelerators aren't
a problem.

I certainly have seen this issue raised, but I'd like to observe
that they also exist for TLS without client auth (it's one reason
why we designed S-HTTP the way we did) but people seem willing
to live with that.

> assumption that there are practical problems that prevent server
> certificates from being validated.  Given this assumption I don't
> understand how TLS actually gives us protection against the
> hijacking.

Imagine a case where you have credentials that have CRA but not
HRA. A good example is Boneh's PwdHash, which includes the
domain name of the server in the "password". If it's
restricted to use with SSL/TLS then you know that each RP
will have a unique domain name and therefore each
"password" is unique to a single RP, so there's automatic
CRA--if the user is phished the phisher must pose as a 
different RP because he has a different certificate. [0]

Note, however, that if you use TLS in NULL mode so that the
password can be captured by a passive attacker, then he
can issue a new request to the same server, thus mounting
cut-and-paste attacks. This isn't strictly hijacking, nbut
it's effectively the same for our purposes, since HTTP is 
connectionless. (I'm not sure I got the terminology on this
feature exactly right).

>  about hijacking in some situations.

By hijacking, I mean network level hijacking. If you mean typos
and phishing, then I think this is a different threat.

-Ekr

[0] Remember that phishing's attack on cert validation is at the
interface between the user's intention and the domain name,
not at the interface between the certificate name and the domain
name.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Jul 2006 14:55:56 -0400

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

    >> authentication.  As I understand HTTP, that is only true
    >> assuming there are no proxies between the user and the RP.

    Ben> HTTP proxies support the CONNECT method for this (all they do
    Ben> is copy the raw connection data in both directions). Note
    Ben> that if proxies didn't do this, then server authentication
    Ben> would also be impossible.

I'm sorry, I mean no non-connect based proxies.
I.E. proxies that are HTTP hops.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Jul 2006 15:07:57 -0400

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
    >> (remember, the token is bearer). If you take the threat of this
    >> type of attack seriously, you need to run the traffic over
    >> SSL/TLS. [1]
    >> 
    >> 
    >> [1] Note that if you're worried about this class of attack, you
    >> need *every* PDU to be cryptographically bound to the
    >> credential with all designs. If, for instance, you use
    >> cert-based auth but then transition to cookies over HTTP for
    >> state management, there's a cut-and-paste attack there.
    >> 
    >> 
    >> I think the primary paragraph is misleading.  We've started
    >> from an assumption that there are practical problems that
    >> prevent server certificates from being validated.  Given this
    >> assumption I don't understand how TLS actually gives us
    >> protection against the hijacking.

    Eric> Imagine a case where you have credentials that have CRA but
    Eric> not HRA. A good example is Boneh's PwdHash, which includes
    Eric> the domain name of the server in the "password". If it's
    Eric> restricted to use with SSL/TLS then you know that each RP
    Eric> will have a unique domain name and therefore each "password"
    Eric> is unique to a single RP, so there's automatic CRA--if the
    Eric> user is phished the phisher must pose as a different RP
    Eric> because he has a different certificate. [0]

This is not true of all credentials that have cra but not ha--or at
least I don't see why it is.  TLS only provides security because you
bind the two authentication layers together by using the same naming
for both the TLS authentication and the higher layer authentication.
(It also assumes that your CA is trusted; that assumption seems
consistent with our threat model.)

I was explicitly trying to get at the fact that you needed to do
something in addition to TLS.  Here you've made the naming be the
same.

    >> I also think the footnote ignores an important deployment
    >> model.  I may be concerned about whether I have reached the
    >> right RP while not concerned about network level hijacking.  So
    >> I'm not at all convinced that you always need to protect every
    >> exchange if you are concerned about hijacking in some
    >> situations.

    Eric> By hijacking, I mean network level hijacking. If you mean
    Eric> typos and phishing, then I think this is a different threat.

Can we have a name for that threat, because I thought you were lumping the two together.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Jul 2006 12:29:31 -0700

> something in addition to TLS.  Here you've made the naming be the

Sorry, I don't see what you're getting at. PwdHash is specified to use
the domain name of the server as the hash salt. RFC 2818 requires
that that domain name match the server's certificate. There's nothing
additional required.

> lumping the two together.

Uh, I call the other one "phishing" or "credential capture"

-Ekr

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Jul 2006 15:56:11 -0400

>>>>> "Dick" == Dick Hardt <[email-masked]> writes:

    Dick> Agreed. My point is that it is much easier to solve it in
    Dick> one place then on all sites. The IdP can become a
    Dick> combination of client side and server side code to deal much
    Dick> more effectively with the phishing issue. It is unreasonable
    Dick> for every site to do that.

I'm missing something here.  Long term, it seems like all the clients
are going to need to change so that they can interact with the new
IDPs.  Long term, the servers are definitely going to need to change
so they can accept information from the IDPs.  I don't see why it is
unreasonable to solve this on all sites long-term.  In fact, I believe
we're going to have to in order to deal with my requirement 4.4
(mutual authentication).  And yes, I think that requirement is really
important because without it, you don't have assurance that you aren't
giving personal information to the wrong party--you don't have
assurance that you aren't being phished.

I think the question we should be asking in this space is whether
there is something we can do in short-to-medium term that has
acceptable intermediate security.  A quetion you're presumably
interested in is whether DIX or something close to it would be such a
something.

I don't know what my answer to that question is.  I hope to have
decided by the end of the BOF.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Jul 2006 16:40:46 -0400

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    Eric> Sorry, I don't see what you're getting at. PwdHash is
    Eric> specified to use the domain name of the server as the hash
    Eric> salt. RFC 2818 requires that that domain name match the
    Eric> server's certificate. There's nothing additional required.

The additional thing is that the specification of pwdhash uses the
        same naming for servers that tls does and that as pwdhash is
        used, it derives the name of the server it is contacting from
        the same place as TLS (the URI).

Say I replace pwdhash with an authentication scheme where the client
needs to learn from the user an identity for the server to be used at
the TLS layer (the domain name from the URI) and an identity to be
used for my upper layer authentication scheme (derived somewhere
else).

For example, SASL digest effectively names the server based on a
realm.  There's no good mapping between the server's domain name and
the realm.  So, I'm fairly certain that a server could trick you into
giving it a challenge to replay with another server.

I think HTTP digest works approximately the same way.
In this situation, TLS would not be enough to prevent MITM.

Although perhaps the difference here is that I was using a broader
definitiong of hi jacking than you were and my definition included
MITM.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Jul 2006 15:03:15 -0700

>         the same place as TLS (the URI).

Yes, I agree that this is necessary. I don't agree that it's
"additional". It's a basic part of any design that aims
to preserve referential integrity, which is why TLS and
PwdHash both do it.

> definitiong of hi jacking than you were and my definition included

Uh, no. The difference is that HTTP Digest and SASL Digest don't
provide CRA, because they don't include the user's intended
URI in the C-R response.

-Ekr

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Jul 2006 18:31:21 -0400

>>  The additional thing is that the specification of pwdhash uses
    >> the same naming for servers that tls does and that as pwdhash
    >> is used, it derives the name of the server it is contacting
    >> from the same place as TLS (the URI).

    Eric> Yes, I agree that this is necessary. I don't agree that it's
    Eric> "additional". It's a basic part of any design that aims to
    Eric> preserve referential integrity, which is why TLS and PwdHash
    Eric> both do it.

OK.  It was not obvious in your definition of CRA that you meant this.

I thin my major conclusion from WEA so far is that reasonably
intelligent people who have been thinking about these problems for
years still find it difficult to agree on common vocabulary.
Requirements and solutions are harder.

---

From: "Gavin Baumanis" <[email-masked]>
Date: Fri, 07 Jul 2006 11:21:41 +1000

Sam, (And everyone else too)
 
Couldn't agree more.
And having no previous experiencing in work at such a low level - it
all seems harder again...
though I am becoming very enlightened!

---

From: Dick Hardt <[email-masked]>
Date: Thu, 6 Jul 2006 21:32:53 -0700

> assurance that you aren't being phished.

I'll see if I can clarify:

1) Most sites are not targeted by phishers today, and unlikely to be  
targeted in the future, so they should not be forced to put in  
technology for resolving phishing.

2) Currently the user has NO trusted site or client and is easily  
phished. Once the user has one trusted software system, then that  
system can more easily determine the identity of other sites. In  
other words, the user will not have to build up the full assurance  
stack with each site, the user can leverage something they already  
trust to assist in making the trust decision.

> interested in is whether DIX or something close to it would be such a

Agree that we need to work on a a short-to-medium term improvement.
Phishing, like most complex problems, likely requires a combination  
of things to minimize.
Per my comments above, once the user has a trusted identity agent,  
DIX could be used by the user to interact in a more trusted manner  
with other sites, with a lower burden on those sites.

> decided by the end of the BOF.

I think the BOF is going to be interesting -- uncertain on what will  
be answered. :)

-- Dick

---

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Jul 2006 10:19:23 -0400

>>>>> "Dick" == Dick Hardt <[email-masked]> writes:

    Dick> 1) Most sites are not targeted by phishers today, 
and
Agreed.

    Dick> unlikely to be targeted in the future, so they should not be
    Dick> forced to put in technology for resolving phishing.

Disagree.  As you start to see reuse of identity, you will see people
moving from targeting primary targets to targeting other sites where
credentials may be harvested.

I think anyone who accepts identity information will ultimately be a
target.

    Dick> 2) Currently the user has NO trusted site or client and is
    Dick> easily phished. Once the user has one trusted software
    Dick> system, then that system can more easily determine the
    Dick> identity of other sites. In other words, the user will not
    Dick> have to build up the full assurance stack with each site,
    Dick> the user can leverage something they already trust to assist
    Dick> in making the trust decision.

I more or less completely disagree with the above, especially with the
idea that the user will ever have one trusted software system.