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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf