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

[Chris Newman <[e-mail]>]

--On January 30, 2008 18:52:01 -0800 Dan Harkins <[e-mail]> 
wrote:

>
>   Hi Chris,
>
> On Wed, January 30, 2008 3:12 pm, Chris Newman wrote:
>> [e-mail] 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.
>
> Why would you put all that cruft into the TLS stack? That's what protocol
> layers are for, abstracting out this complexity.

Agreed.  This doesn't belong in the TLS stack so it shouldn't be in the TLS 
protocol.

> What do you do for supporting certificates? For RFC2885 support do you
> have HTTP and FTP support to obtain certificates and CRLs from
> repositories built into the TLS stack? Is the entire OCSP protocol part
> of your TLS stack? What about CMS? Et cetera.

The server I work on only supports client certificates signed by a locally 
stored CA cert (and locally stored CRLs) for TLS authentication and it's 
difficult to keep it working because the extra layering through the TLS 
stack makes it more fragile than other authentication code.  There's OCSP 
support in the TLS stack, but the server doesn't enable it -- it'd probably 
be problematic since the application would have limited control over the 
OCSP connections and that won't be viable in a highly scalable server.

>> 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.
>
> Channel bindings are orthogonal to a password-based authentication
> protocol.

Not for one that does mutual authentication.

>> 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.
>
>   Dubious utility? Wow. They are arguably the predominant method used for
> network access in the Internet today, and for the past umpteen years.

I've never seen TLS PSK used so I question your assertion.

>   One lesson I learned very hard from IKE was that if your protocol does
> not handle username/password authentication then people are going to hack
> the hell out of it to put it in, to the detriment of protocol security.
> Why do you think the "do not validate server certificate" checkbox exists?
> Let me give you an actual quote I heard: "to make SSL work".

That's why I'd prefer to keep TLS out of the game of application 
authentication.  The TLS stack is too critical as a mechanism to provide an 
encrypted tunnel (it's debatable if the server authentication in TLS is 
useful for the reason you cite).

IKE got into the game of application authentication because VPNs are the 
primary deployed use for IPsec/IKE and the VPN application has all the 
standard application authentication requirements.

		- Chris

_______________________________________________
TLS mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/tls