[Emu] Review of draft-pala-eap-creds-00

[Alan DeKok <[e-mail]>]

  This is a short review of draft-pala-eap-creds-00.  In short, the idea looks good.

Section 2:

   This specification addresses the problem of providing a simple-to-use
   and simple-to-deploy system for credentials management by extending
   the EAP protocol to support credentials provisioning and management
   functionality.  In particular, the EAP-CREDS method defined here
   provides a generic framework that can carry the messages for
   provisioning different types of credentials.  The method can be use
   as a stand-alone method or it can be used as an inner method of EAP-
   TTLS or EAP-TEAP which can provide the required encryption and
   server-side authentication to deliver server-side generated secrets
   (e.g., private keys, passwords, secret keys, etc.)


  My $0.02 is to forbid use of it as a stand-alone method.  There's just no reason to send credentialing information in cleartext.

  I'd also remove the explicit references to TTLS and PEAP.  Just say it can be used inside of another secure EAP method.

Section 5.1:

         |------------ EAP-Response/Identity -------------->|
         |      (NAI=register@realm|NAI=manage@realm)       |

  That will need to change.  RFC 7542 suggests that the "name" portion of an NAI is completely under the control of the local realm.  i.e. we just can't standardize names in someone else's space.

  There is a solution though.  We may be able to use "arpa", as with "home.arpa":

     https://www.iana.org/domains/arpa

  We could define "provisioning.arpa" or something similar for this purpose.  And then since it's owned by the IETF, we can define new things in it.

  Sections 8.1 and 8.2 can likely be deleted.  We don't need to see additional protocol flows for those EAP methods.

  If we do need to discuss other EAP methods, the text should say how CREDS interacts with them.  e.g. how it's different from the flows normally carried by those protocols.

  I think this anonymous provisioning is very useful.  It's been re-invented a few times in non-standard ways, which is an issue.

  The document should also discuss fragmenting.  A fragmentation method as done with TLS or EAP-PWD is relatively simple, and well known.

  It should also note that sending more than 64K of data as part of CREDS is likely to not work.  The outer EAP methods / access points will likely give up before 64K of data have been exchanged.

  The document could also discuss security and bootstrapping in more detail.

  i.e. an EAP SUCCESS here does not mean that the user has gained network access, and should be allowed unrestricted access to the net.  It could be useful instead to suggest that the credential negotiation is part of "CREDS", and the "EAP" portion *always* returns FAIL.  This is so that the user never gains unrestricted network access as a result of CREDS negotiation.

  The client should also know it's talking to a known and trusted authentication server.  Perhaps the document could suggest that the outer EAP method uses a certificate signed by a known root CA.

  It may also be useful to discuss limited network access via domain names, as was discussed with EAP-TLS.  If we can define a "provisioning.arpa" domain, then we can standardize "walled gardens" based on that.

  i.e. someone requests anonymous access, and then gets a real IP network, where they can run any standard provisioning protocol.  That simplifies the problem we're trying to solve, and may avoid the need for yet another protocol.

  These issues need to be discussed in a lot more detail before the problem statement, and solution, are clear.

  Alan DeKok.