>>>>> "Glen" == Glen Zorn <[email protected]> writes:
Glen> If certificate-based TLS authentication is used & the TTLS
Glen> server is located in the visited network (something that the
Glen> client can check by matching the identity advertised with a
Glen> name in the cert), the task is accomplished (in that the
Glen> problem becomes one of policy, provisioning and implementation
Glen> rather than protocol design or standardization).
Glen, thanks for explaining this. I now believe I understand what
you're proposing.
Like Alan, I'm concerned about the security and privacy implications of
have the TTLS server be in the visited network in a different
organization.
However we can do something similar. We could have the home AAA server
use a different EAP server or at least different TLS certificate for the
corporate network than for other networks. From the standpoint of the
client I think this is very similar to what you describe. It has some
advantages, including that we don't need to ask visited networks to
change their configuration or deploy TTLS servers.
I agree that works for the case I proposed. However I do not prefer it
as a solution.
At this point , I think we understand each other's positions and have
clear disagreement. We are not going to be able to change each other's
minds. So, the WG will have to come to consensus on whether channel
binding has value.
For the record, here are the reasons I prefer channel binding to using
different certificates to distinguish properties of the network.
Channel binding scales better on dimensions that I care about. For each
set of attributes that a client wants to distinguish I need a separate
certificate with the TLS approach. With channel binding, the client
simply needs to give these attributes to the EAP server. Significantly
increasing the number of certificates is likely to complicate management
of the client and of the PKI within the organization. If an external CA
is used, this may involve a significant cost.
Using TLS certificates tends to require that all clients want to
distinguish the same attributes of the network. With channel binding,
two clients can send a different set of attributes for validation
against the channel binding information. The certificate approach seems
like it will be very complicated especially when an organization wishes
to change the set of attributes that clients wish to distinguish.
I think channel binding does less damage to the conceptual EAP model
than this TLS approach. Today in EAP, the peer authenticates to the
issuer of its credentials; given a credential, a peer typically knows
who the other party will be. Trust management between the peer and EAP
server is relatively simple in this model. However, if TLS certificates
represent networks rather than credential issuers, then the conceptual
parties in the security model change. I think that complicates trust;
the privacy issues Alan brings up are the most obvious example. In
contrast, I at least believe that channel binding fits within the
existing EAP model. Certainly, we've done a lot of analysis including
the EAP keying framework and the AAA key management requirements
assuming such a facility and this analysis does not appear to have shown
a disconnect between the EAP model and channel binding.
I'll note that channel binding appears very easy to add to TTLS.
However, there is one case where the of multiple TLS certificates may
provide a significant benefit over traditional channel binding. If there
is an entity trusted by the client that is significantly closer to the
NAS than the home EAP server, then having a TTLS tunnel to that entity
may provide a point that is in a better position to make statements
about the NAS. I'll note that this approach has significant power when
combined with channel binding. However it seems like there is a lot of
complexity involved and issues to work through. It seems like having
trust relationships with all these entities in the network will require
a fairly complex PKI or complex client management. It seems like this
approach is getting away from the AAA model, which at least as I
conceptualize it has a major goal of limiting the trust management of
the client. Figuring out when to route an EAP conversation through such
an endpoint seems kind of tricky; what set of clients is it done for? Do
clients request such routing? If so, how? If not, how is the
cross-organizational configuration managed? Still, I think this use case
is quite interesting and is something we should examine.
--Sam
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
