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
[email protected]
https://www.ietf.org/mailman/listinfo/emu
