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

[Alan DeKok]

  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.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] WGLC for RFC5448bis

[Joseph Salowey]

This is the working group last call for draft-ietf-emu-rfc5448bis-04
.  Please send
your comments to the list by 3/1/2019.

Thanks,

Joe and Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu