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" <hartmans-i...@mit.edu> 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 >Emu@ietf.org >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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
