> I certainly agree with attacking the cause rather than symptom. But a > portion of Sam Hartman's draft is in fact dealing with a cause of the > symptom. Namely the part that is trying to protect user credentials > from disclosure to an unauthorized party -- by proposing to eliminate > the near ubiquitous phenomenon of sending passwords over TLS to an > application server. And using proper cryptographic authentication > techniques that don't transmit long-lived passwords or keys over the > network period. It's about time the IETF stood up and said that. I agree with that. > We can have a discussion about whether long lived human memorizable > passwords have a future. But we have to deal with the reality today. Why is it an either/or? Can't we do both? My issue with was with saying that solutions MUST support passwords. > I suppose that some time in the distant future we might all be using > public key authentication... but we > are very far from that world. Smartcards aren't the only alternative here. For example, folks in the KEYPROV WG make an argument that token authentication has the potential to become a mass market phenomenon. > Should we be recommending non-reusable passwords or > smartcards/tokens everywhere? Frankly, I think it would be best if the IETF would develop solutions compatible with a range of approaches, and let customers choose. > Even if you've protected your authentication credentials, not > trusting endstation software means that you may not be able to > conduct any private or sensitive tasks on it. Right. But there's a difference between violation of privacy and being able to empty someone's bank account. It's a distinction that is worth making, and one which the current document is not clear about. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf