Pasi.Eronen@xxxxxxxxx wrote on 1/30/08 9:58 +0200:
Dan Harkins wrote:Personally I would view a password-based authentication scheme that assumes the shared key is a low-entropy one or is selected from a limited set of keys, like a dictionary, as more useful to the real world. I believe that is the predominant access method used in the Internet today.Just being curious, what would be the main differences between the authentication scheme you're thinking about, and RFC 5054?
On the protocol side, not much.On the implementation side, it would roughly double the complexity of a typical TLS API in order to actually be useful to applications. The password verifier could be stored in any one of a number of external repositories (LDAP, RADIUS, DIAMETER, SQL, Liberty, some other SOAP/HTTP mechanism, /etc/passwd, NIS, etc) and the application would have to provide the TLS stack with sophisticated configuration knobs related to these protocols. As a matter of efficiency, some of these protocols are not cheap so high performance servers will have to keep a pool of connections, then fetch and cache the information locally. Attributes that are peripherally related to authentication or unrelated to authentication may also be accessed via these protocols and need to be cached as well to avoid the need for double-fetching of the same entry. So the API needs a way to put all sorts of controls on the protocols used to fetch this data, timeouts, what attributes are of interest, caching parameters, etc. Then there's need for back-channels to the cache (flushing specific entries on provisioning changes) which means hooking up to a notification mechanism to the caching logic under the TLS stack.
Personally, I think TLS stacks are plenty complex enough without all this machinery. As a matter of architecture, I'd rather keep this machinery completely separate from the TLS stack and use TLS channel bindings when mutual authentication at the application layer is needed.
Although I'm dubious of the utility of PSK, it seems mostly harmless to the TLS stack as long as it's not a password. The primary utility I see for PSK would be for server->server connections if it's coupled with an SSH-style zero-configuration key setup mechanism (I don't see it as having much real-world utility without the latter piece). If PSK proves to be useful than ECC-PSK is also likely to be useful simply because of the improved key scalability.
- Chris
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls