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

From: Carolin Latze <[email-masked]>
Date: Fri, 13 Jul 2012 14:10:54 +0200

Hi all,

we just uploaded a new version of the draft-josefsson-sasl-external-channel:

http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-05.txt

This is an upgrade of a pretty old draft which has been discussed on the 
SASL list in the past:

http://www.ietf.org/mail-archive/web/sasl/current/msg00427.html

By then, the main issue was the lack of an use case which we believe we 
found now. We came with the requirement to use multiple certificates 
within the same authentication exchange. Some applications (like BYOD in 
some companies) want to make use of an user and a device authentication. 
Access should only be granted if user *and* device can be authenticated. 
One way to do that is to set up a secure tunnel where you authenticate 
the device and then run user authentication inside that tunnel. However 
that costs some resources. Therefore, we upgraded the I-D to allow for 
chained, renegotiated TLS handshakes in the EXTERNAL-TLS mechanism to 
support this use case.

Best regards
Carolin

---

From: Chris Newman <[email-masked]>
Date: Mon, 16 Jul 2012 11:30:08 -0700

I'm very dubious of this claim in the abstract.

>  This has impacted the interoperability of the EXTERNAL mechanism.

Perhaps that claim should be either removed or supported with documentation 
in an appendix.

We're also in a situation where we're just starting to get partial 
interoperability of TLS client certificate authentication with SASL 
EXTERNAL in the installed base of Internet email services (there have been 
numerous interoperability problems in that space, although I'm not aware of 
any problems due to the specification of the EXTERNAL mechanism).

I'm concerned that muddying the waters by introducing EXTERNAL-TLS may 
produce more interoperability problems. However, that concern would be 
largely mitigated if this document added a statement along the lines of:

 Clients that use EXTERNAL-TLS SHOULD be able to use EXTERNAL for the same 
purpose in
 order to interoperate with deployed server software that presently only 
implements
 EXTERNAL for use with TLS.

 Servers that advertise EXTERNAL-TLS SHOULD also advertise EXTERNAL in 
order to
 interoperate with deployed client software that presently only implements 
EXTERNAL.

		- Chris

--On July 13, 2012 14:10:54 +0200 Carolin Latze <[email-masked]> 
wrote:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 19 Jul 2012 16:29:45 +0200

Chris,

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.

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

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.

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?

If we can get consensus on updating EXTERNAL, that would be fine, but if
that doesn't happen I think adding the text you provided is a good
compromise.  Revising EXTERNAL may bring up other issues that I haven't
thought about though, so that is why I have hesitated.

/Simon

Chris Newman <[email-masked]> writes:

> Perhaps that claim should be either removed or supported with
> documentation in an appendix.
>
>
> EXTERNAL in the installed base of Internet email services (there have
> been numerous interoperability problems in that space, although I'm
> not aware of any problems due to the specification of the EXTERNAL
> mechanism).
>
> Clients that use EXTERNAL-TLS SHOULD be able to use EXTERNAL for the
> same purpose in
> order to interoperate with deployed server software that presently
> only implements
> interoperate with deployed client software that presently only
> implements EXTERNAL.
>
> 		- Chris
>
> --On July 13, 2012 14:10:54 +0200 Carolin Latze
> <[email-masked]> wrote:
>
>> Hi all,
>>

---

From: Chris Newman <[email-masked]>
Date: Fri, 20 Jul 2012 08:45:15 -0700

--On July 19, 2012 16:29:45 +0200 Simon Josefsson <[email-masked]> 
wrote:
> 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.

> does not use any authorization identity for simplicity, although this is

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.

> interoperability, client and server need to negotiate out of band what

I would have no objection to this change.

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

> IPSEC or some other security protocol.  Is anyone aware of any such

No.

		- Chris

>>> http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-chann
>>> el -05.txt
>>>