On 6/29/06, Sam Hartman <[EMAIL PROTECTED]> 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 PROTECTED]
http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
