Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements

Sam Hartman <hartmans-ietf@mit.edu> writes:

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

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

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

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.

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

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.

>                       TLS Client AUthentication
>
> Your taxonomy assumes that TLS is a valid approach to client
> 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
> there are no proxies between the user and the RP.

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.

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

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

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

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.

_______________________________________________
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix