Re: [kitten] [Emu] Right place for ABFAB ephemeral keying

[Josh Howlett <[e-mail]>]

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" <[e-mail]> wrote:

>
>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?
>_______________________________________________
>Emu mailing list
>[e-mail]
>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