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

["Ben Laurie" <[e-mail]>]

On 6/29/06, Sam Hartman <[e-mail]> 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
> [e-mail]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
>

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