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

["Dan Harkins" <[e-mail]>]

  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.

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.

> 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.

> 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.

  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".

  Dan.





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