Subject: Re: [kitten] draft-josefsson-sasl-external-channel-05.txt

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Aug 2012 10:29:43 +0100

On 20/07/2012 16:45, Chris Newman wrote:
> --On July 19, 2012 16:29:45 +0200 Simon Josefsson 
> <[email-masked]> wrote:
>> I share your concern, although the reason for not saying anything like
>> what you suggest is that, today, EXTERNAL and EXTERNAL-TLS semantically
>> are different beasts.  I believe the EXTERNAL-TLS semantics are more
>> useful. It seems the deployment you refer to support that notion as
>> well: they use EXTERNAL precisely what we want EXTERNAL-TLS for.
>> The problem is that EXTERNAL can be used for other things too, and there 
> is
>> no way of knowing which purpose was intended.
>
> Honestly, I see no real-world problem here. Yes, there's a minor 
> semantic difference between "use available credentials" and "use 
> available TLS credentials" but I don't see why it would matter to a 
> client that has gone through the trouble of being configured to 
> provide TLS client certificates.
>
>> To illustrate the problem, consider an application running over IPSEC
>> that does IMAP with STARTTLS.  The client see EXTERNAL announced from
>> the server.  The app wants to authenticate to the IMAP server using its
>> TLS credentials.  The app does not want to use its IPSEC credential to
>> authenticate to the IMAP server.  If it does 'AUTHENTICATE EXTERNAL' the
>> client doesn't know which credential was used for authentication, and it
>> isn't deterministic which account it was logged into.  (This example
>> does not use any authorization identity for simplicity, although this is
>> the most common usage.)
>
> I know of no such implementation, nor of anyone conceiving of such an 
> implementation. First, no IMAP server will advertise EXTERNAL as a 
> result of IPSEC. The problem is that IPSEC uses host credentials which 
> can't be mapped to an end-user account (or if it uses end-user 
> credentials, there's no standard API to get them from the OS), so it 
> doesn't provide any useful credentials for end-user authentication 
> purposes so any IMAP server that advertised EXTERNAL without a useful 
> mapping to end-user credentials would be at least broken and probably 
> incompliant. Even if IPSEC could provide end-user credentials, those 
> credentials would almost always be the correct ones and the client 
> need not worry.
>
> So your strawman presumes 4 unlikely events: 1. someone uses IPSEC. 2. 
> IPSEC uses end-user credentials which imapd can access through a 
> supported API. 3. The IPSEC end-user credentials differ from the mail 
> account identity. 4. The client both cares which mail account is 
> accessed and fails to provide the mail account authorization identity 
> to the EXTERNAL mechanism.
>
> That scenario is at best an unlikely misconfiguration, if not a broken 
> client. I still think this is all trying to solve a non-existent problem.

Agreed. The only other non-TLS use case I've seen for SASL EXTERNAL was 
over a Unix domain socket.

>
>> I believe the text you provided would be good, and we'd be happy to add
>> it.  There is another solution though:
>>
>> How do you feel about revising the EXTERNAL mechanism specification to
>> say that it refers to the credentials negotiated under TLS, similar to
>> what's in d-j-sasl-external-channel?  Currently EXTERNAL refers to
>> anything outside of the application protocol, and to get security and
>> interoperability, client and server need to negotiate out of band what
>> is intended.
>
> I would have no objection to this change.
>
>> Compare how we "updated" the GSSAPI mechanism to be for Kerberos V5
>> only.  We could update EXTERNAL to be for TLS only, and permit future
>> specification of EXTERNAL-SSH or EXTERNAL-IPSEC for "external" SASL
>> authentication with other security protocols (if someone cares about
>> that).
>>
>> I find EXTERNAL to be rarely used because applications cannot
>> auto-detect when it is appropriate to use, and when it is used, in my
>> experience it always means to use the TLS-negotiated credentials.
>
> There are two useful models for clients:
> 1. explicit end-user selected security mechanism/policy
> 2. latched auto-select security policy: the client looks for the best 
> option that works, and records that it worked with that server and 
> requires security at least that good in the future to prevent 
> downgrade attacks.
>
> Most clients do 1 because it's much less complex to implement/debug 
> even if it does leave the choice up to the end-user. On top of that, 
> it's even more difficult to auto-select the intended client 
> certificate (which client certificate is associated with which mail 
> account?). So if you have to make the end-user manually configure TLS 
> client cert authentication anyway, may as well keep the code simpler.
>
> The other problem is the wide deployment of non-interoperable 
> protocols when it comes to TLS client certificate authentication. 
> There are ones where we botched the IETF specifications (SMTP), so 
> there are servers that require EXTERNAL, servers that disallow 
> EXTERNAL and servers that do or don't use client certificate 
> credentials as a side-effect of the STARTTLS command and there's 
> usually no way for the client to tell the difference. Most SMTP 
> clients are lazy and just send the TLS client certificate and hope it 
> works. Then there's the non-standard imaps and pops protocols that 
> have unspecified behavior (and often do not interoperate when it comes 
> to client certificate authentication).
>
> At least there's no excuse for non-interoperable STARTTLS client 
> certificate authentication in IMAP and POP because that was 
> standardized unambiguously in 1999.
>
> Of course, there's also the problem that deploying and managing a 
> certificate infrastructure is a huge amount of work so for most 
> deployments the incremental security (if any) isn't worth the cost.
>
> I don't think making EXTERNAL more complex will improve deployment of 
> TLS client certificate authentication. Frankly, spending time on DANE 
> specification and implementation would probably be a better investment 
> if the latter is your goal.
>
>> The EXTERNAL-* idea is mostly to formalize one use-case for EXTERNAL.
>> We could modify d-j-sasl-external-channel and say that for historical
>> reasons EXTERNAL-TLS is actually called EXTERNAL, and then supersede
>> Appendix A of RFC 4422 with this document.  The only problem this would
>> cause, that I can identify, is if someone is using EXTERNAL to mean
>> IPSEC or some other security protocol.  Is anyone aware of any such
>> usage?
>
> No. 

+1 to all of this.

---

From: Carolin Latze <[email-masked]>
Date: Fri, 17 Aug 2012 10:23:45 +0200

So in order to provide a solution for the use case of having multiple 
certificates within the same authentication exchange, you would prefer 
to use EXTERNAL with TLS and then renegotiation as proposed in the 
current draft?

On 08/10/2012 11:29 AM, Alexey Melnikov wrote:
>> result of IPSEC. The problem is that IPSEC uses host credentials 
>> which can't be mapped to an end-user account (or if it uses end-user 
>> So your strawman presumes 4 unlikely events: 1. someone uses IPSEC. 
>> 2. IPSEC uses end-user credentials which imapd can access through a 
>> That scenario is at best an unlikely misconfiguration, if not a 
>> broken client. I still think this is all trying to solve a 
>> non-existent problem.
>
> Agreed. The only other non-TLS use case I've seen for SASL EXTERNAL 
> was over a Unix domain socket.
>
>>
>> have unspecified behavior (and often do not interoperate when it 
>> comes to client certificate authentication).
>>
>> specification and implementation would probably be a better 
>> investment if the latter is your goal.
>>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten