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
