At Sat, 18 Aug 2007 07:25:14 +0200,
Eliot Lear wrote:
Hi Eric,
I have one overall comment and one specific comment on your comments ;-)
The overall comment is that we need a starting point to improve HTTP.
Sam's draft seems to me at least a stake in the ground from which to
work with.
Yeah, I don't think the world is improved by putting a stake in the
ground at a poorly chosen location [nor, for that matter, do I agree
that necessarily HTTP is the correct location for improvement.] And as
I argue in my review, we don't understand the ground well enough to
place it in a good location.
I'm all for the document being improved. It would be
helpful if you could suggest changes to the text to do that. I realize
that's a lot more work, but I think we really can put a huge dent in
phishing, and we don't need to wait around for academia on this one.
I'm afraid I don't agree with either of these assertions, for the
reasons I indicated in my review.
The IETF needs to address areas where protocols are currently unable to
support secure authentication methods.
It's yet to be established that there is anything wrong with the
protocols at all. On the contrary, the current protocols appear
to me to be quite capable of doing most of what one would want
if coupled with the appropriate UI. And it's the UI issues that
are poorly understood.
S 4.1.
A solution to these requirements MUST also support smart cards and
other authentication solutions. Some environments have security
requirements that are strong enough that passwords simply are not a
viable option.
This seems premature. Moreover, it again confuses interface with
protocol. To take an example, SRP can be used perfectly well with
smartcards: you do the client-side computation on the smartcard.
Pretty much any password-based solution can be ported to smartcards
simply by placing the password on the card. Calling out smartcards
in particular is also way too specific.
I think perhaps we have a terminology issue. By password, I think Sam
means those things people type into UIs. By smartcards I think he means
something that does it for you in some secure way not specific to the
IEEE standard. The major point that Sam is calling out, and he is doing
so at my urging, is that we need to be able to support a solution where
the authentication component is separate from the host operating system,
yet having a secure communication channel from end to end. This may
need to be wordsmithed but that's the intent.
Yes, and the point that I'm making is that this is a UI issue, which
is largely orthogonal to the protocol. In fact, with properly designed
protocols one side can be quite oblivious to where the peer's
credential is stored--though of course restrictions can be enforced
by restricting direct access to the keying material. And that's
the issue: this document repeatedly conflates UI and protocol.
As for the term "smartcard", if you don't mean ISO 7816/7810, then
you should choose some more generic term. I believe "token" is the
one currently in vogue.
-Ekr
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf