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

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

  Hi Chris,

  It sounds like your TLS implementation is a horribly complex mess.
I'm very sorry about that but please realize that not everyone's is.
It's possible to implement password-based authentication without
"doubling the complexity" (as you claimed) but then maybe not with
all TLS implementations. Your mileage may vary, and apparently may
vary considerably.

  Nobody said anything about "application authentication" so that's
just a red herring.

  Also I don't know what's debatable about the benefits of server-side
authentication in TLS unless you want to enable phishing expeditions.
Most people don't.

  best regards,

  Dan.

On Wed, February 6, 2008 1:37 pm, Chris Newman wrote:
> --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