Subject: [saag] Need a public key authentication for SMTP etc.

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Oct 2015 12:04:52 -0400

Note the use of the definite article. I want exactly one mechanism for
authenticating SMTP, IMAP, POP3 etc server to a client.

Looking at the EAP list we seem to have two dozen authentication
schemes. That is no help, there should be one authentication mechanism
for public key.

In the proposed mode of deployment, every user will be identified by
the fingerprint of their public 'master signing key' which is a long
lived key that does not have a predetermined expiry.

Devices assigned to a user will be identifier by a unique device key.
These are bound to the master key via a certificate chain (using JSON
data structures, not X.509). Since people add and remove devices
periodically, these are going to change over time.

So the configuration file for the mail server is likely to look
something like this:

[email-masked]/MCGJJ-RLX4O-EDSHN-XZBRF-DWE3L-2XW3J
[email-masked]/MDDZJ-AMXZW-2XZ76-U26H3-X6TEW-KCANU
...

Assume that I have an infrastructure that makes it easy to provision
the keys to devices, manage application profiles and allow a relying
party to obtain the necessary trust chain.

The user is going to have a matching application profile something like this:

"MailProfile" : {
    "AccountID": "[email-masked]",
    "Inbound" : {
        "Service" : "imap3.example.com",
        "Port" : "993",
        "Protocol" : "IMAP",
        "Transport" : "TLS",
        "EAP" : "XXX"
        }
    }

So what to put in "XXX" ?

I want one choice that provides secure authentication on the basis of
a choice of RSA or DH keys that is secure against replay attack, MITM
attack, etc.

It is possible that we would want to use TLS client auth in addition
to EAP but I am not a fan of using transport authentication  for
application clients. The problem being that when an accelerator is
used, the binding between the authentication validation point and the
application server becomes weak.

Any implementation is going to require new code at the client and the
server. Therefore I am expecting this would use the CFRG ECC
algorithms.

I would like to be able to use the same algorithm in HTTP. So if HTTP
Auth actually came to any convergence then it might make most sense to
use that.

Of course it is quite possible that the whole field has been so
hopelessly bike shedded that the best course for me is to pull out the
dart board and pick one. That could be dangerous though. My darts club
nickname was 'the acupuncturist'.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 30 Oct 2015 12:24:53 -0400

> schemes. That is no help, there should be one authentication mechanism

  The practical choices for EAP are EAP-TLS, PEAP, and TTLS.

> So what to put in "XXX" ?

  If you want to have passwords as part of this process, then PEAP or TTLS.

  Personally, I'd pick TTLS.  It allows for the transport of additional data inside of the TLS tunnel, where PEAP does not.  This is good for future extensibility.

> application server becomes weak.

  You may also want to look at moonshot:

https://wiki.moonshot.ja.net/display/HOME/Home

  They've added EAP authentication to a lot of applications.  It's deployed now, it works, and the code changes are surprisingly small.

> Auth actually came to any convergence then it might make most sense to

  Yes.  IMHO passwords should be deprecated where possible, and systems should be encouraged to use EAP.

  Alan DeKok.

---

From: Josh Howlett <[email-masked]>
Date: Fri, 30 Oct 2015 17:28:33 +0000

>   Personally, I'd pick TTLS.  It allows for the transport of additional data inside
> of the TLS tunnel, where PEAP does not.  This is good for future extensibility.

TTLS (and PEAP) also provide anonymity, a desirable property for authentication in federated scenarios (the motivation for Moonshot), whereas EAP-TLS does not (and nor did any of the other PK based methods, when I last reviewed them). Personally I'd welcome work to address this as TTLS is pretty inefficient if all you need is public key authentication. We recommend the use of TTLS for both network and application authentication to our users.

Josh.

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 30 Oct 2015 13:39:24 -0400

On Oct 30, 2015, at 1:28 PM, Josh Howlett <[email-masked]> wrote:
> TTLS (and PEAP) also provide anonymity, a desirable property for authentication in federated scenarios (the motivation for Moonshot), whereas EAP-TLS does not

  RFC 5216 provides for EAP-TLS inside of EAP-TLS, which provides anonymity.

  Alan DeKok.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Oct 2015 13:48:31 -0400

>   If you want to have passwords as part of this process, then PEAP or TTLS.

No, there are no passwords involved. The user does not have a
password. The device has an RSA Keypair or a ECDHE keypair.

This is only for client auth. Anonymity is not a concern as the user
is logging into a named account. Alice is logging into
[email-masked] to read her email.

The way I see the communication going in the ideal case is that the
client knows that it can use TLS a-priori and so there is no need to
do a STARTTLS upgrade.

So layering in a second TLS tunnel inside the first is looking Rube
Goldberg to me. What I was looking for was a scheme of the form:

  C: EHLO client.example.com
  S: 250-smtp.example.com Hello client.example.com
  S: 250 AUTH XXX
  C: AUTH XXX <client-credential> <c-challenge>
  S: 334 <server-ephemeral> <server-challenge>
  C: <client-response>
  S: 235 Authenticated.

I was expecting that there was a mechanism that connected these
directly and it would involve EAP as all the SASL mechanisms seem to
be password based.

This is hard core public key. No passwords.

For symmetric auth, I would use SCRAM with a randomly generated 128
bit password or the like to prevent brute force attack. But that would
actually be a lot harder to implement.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 Oct 2015 18:57:04 +0000

> schemes. That is no help, there should be one authentication mechanism

Why EAP?  If this is to have a decent chance of integration with
a broad range of MSAs in a reasonable timeframe, then what makes
sense (for authentication) is either a SASL mechanism (channel
binding with client authentication via the new PKI, or just SASL
"EXTERNAL" authentication if the new PKI can be made to work as a
TLS ciphersuite with client certs).

> lived key that does not have a predetermined expiry.

In TLS 1.3 IIRC client certificates don't travel in the clear, so
a self-signed client certificate with embedded metadata linking it
to the CryptoMesh PKI would be a good way to go.  The self-signed
cert can be generated on the fly (and cached).  NO X.509 CAs, rather
a sheep in wolf's clothing (raw public key dressed in X.509
splendour).

This can be supported in MSAs without dragging in new and exotic
crypto libraries.

Perhaps I'm missing some implicit requirements, more than happy to
discuss further, and even prototype in Postfix if something practical
emerges from the discussion.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 Oct 2015 19:02:23 +0000

> directly and it would involve EAP as all the SASL mechanisms seem to

SASL also hash "EXTERNAL" and GSSAPI is not password based.
Specifically with GS2 you can expose your new underlying mechanism
as part of the negotiation:

    https://tools.ietf.org/html/rfc5801

then just do a suitable authenticated channel binding with the
user's public key.

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Oct 2015 15:41:23 -0400

> TLS ciphersuite with client certs).

Well it was process of elimination... I couldn't find a SASL mechanism
that did what I wanted so I assumed there must be an EAP.

I am also looking to avoid X.509 here. Yes, even though what I showed
last year was a personal PKI based on PKIX, I found that when it came
to writing actual code, I could not use any of the easily accessible
PKIX chain building code.

It is looking to me like I should just cut a new SASL auth mechanism.

> emerges from the discussion.

Thanks, will bear that in mind. I am just finishing up the profile
manager. Next step is the specs and documentation.

What the Mesh does is to provide a mechanism that replicates
credentials and application configuration data of any type across
multiple devices using strong end-to-end cryptography. So there is a
cloud service (the cryptomesh) but that isn't a trusted service except
with respect to service and that exposure is bounded in time.

Every device, every user, every application has separate sets of
public keys, each of which is separated by function. In 1992 we could
barely process chains of two certs. That isn't a concern today.

The initial application for the Mesh will be to manage usernames and
passwords for Web sites. So the user has six different devices and
three browsers on each but they all have access to the common password
profile.

At the suggestion of David Clark, the next application will be SSH
(and thus Git). Any machine/account you connect to your personal
profile will have access to all the SSH credentials you have stored.