Subject: [Emu] Right place for ABFAB ephemeral keying

From: Sam Hartman <[email-masked]>
Date: Fri, 15 Nov 2013 13:25:01 -0500

Hi.
At the most recent ABFAB meeting I brought up the idea of adding
ephemeral keying to ABFAB.
This would provide the following:

* Protect the EAP conversation between the peer and NAS (initiator and
  acceptor in GSS terms)

* Provide a key to protect ABFAB negotiations 

* Prevent the EAP server or proxies between the EAP server and NAS from
  observing the resulting session

This would help defeat fingerprinting by passive observers as well as
minimize the damage that a passive server could do cooperating with the
home EAP server.  This is more valuable for ABFAB used in protocols like
NFS and CIFS or in RFc 4462 SSH key exchange than it is for ABFAB used
within an TLS session for IMAP, XMPP or SMTP.

Stephen thought the general idea of protecting ABFAB  sounded good but
would prefer that we get better protocol re-use and suggested we look
into protecting EAP in general.  I was dubious of that but suggested
protecting Kerberos GSS in general as an option.

After trying to work through how to protect either EAP or Kerberos, I've
mostly concluded that I don't know how to get significant protocol
re-use.  However I do agree with Stephen that it would be better that
get protocol re-use if we can still implement relatively quickly and
meet all of the above protection goals for ABFAB.

So, here are my thoughts on EAP and Kerberos:

EAP.  Ephemeral keying doesn't belong in an EAP method.  EAP methods run
between the peer and EAP server.  We want PFS between the peer and NAS.
The endpoints are wrong.

We could insert a layer similar to ERP (the hokey produced EAP
Reauthentication Protocol) between the peer and NAS.  It's been a while
since I've looked at ERP, but I seem to recall that ERP runs between the
peer and an entity in the visited domain although it does have specific
NAS support.

That approach would be OK for ABFAB assuming it could be implemented
efficiently.  It would be a bit ugly because you want to start using the
ephemeral key well before EAP has concluded.  However, for lower layers
that do complex keying after EAP concludes, it's probably the wrong
approach.  Also, ERP took a long time to specify.  I don't want to
commit to astandardization effort that complex.

Kerberos.  I was considering trying to share some tokens for ephemeral
keying with Kerberos.  keying wants ephemeral keing within a GSS
mechanism.  You could do that for Kerberos, although you'd need to take
advantage of the not-widely-implemented extension to the magic checksum
used by GSS for channel binding and (in that magic extension) other
extensions.  In ABFAb the framing would be different because our context
tokens have subtokens.  However we could use the same PDU.

Except for two things.  First, Kerberos probably would be happier with
an ap-req and ap-rep extension than a GSS mechanism level extension.
Secondly, Kerberos might well want to use pkinit data structures and
possibly even run a stripped down client-server version of pkinit for
the ephemeral keying.  That's way too expensive in terms of
implementation complexity if you don't already have a pkinit
implementation sitting around.

my conclusion from all this is that the right place to do ephemeral
keying for an EAP protocol is in the lower layer and that unless I got
something wrong or missed an alternative, ABFAb should do its own
mechanism.

Can anyone see a good way to get protocol re-use here?

---

From: Josh Howlett <[email-masked]>
Date: Thu, 28 Nov 2013 11:52:17 +0000

Sam,

I agree with your conclusion. There are example of lower layers using
EAP-based ephemeral keying, and ABFAB could perhaps look to those for
inspiration and perhaps reuse.

Josh.

On 16/11/2013 02:25, "Sam Hartman" <[email-masked]> wrote:

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

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238