RE: [TLS] password-based authentication (was: Some comments about draft-badra-ecdhe-tls-psk-01)

Pasi.Eronen@nokia.com 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@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls