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. 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.
The IETF needs to address areas where protocols are currently unable to
support secure authentication methods.
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.
Thanks,
Eliot
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf