Alejandro and I have been discussing fast-reauthentication over the last couple of days including a very useful lunch discussion today. Here's my thoughts:
There are fairly easy approaches for fast reauthentication to a service you've recently talked to. The Moonshot code includes one such approach as a non-standardized extension. There are a number of common problems when you want to do fast re-authentication between services. The biggest is deciding what realm the service belongs in. In general, you cannot trust the service to help you with this. Consider. evil.com and example.com are both in a federation. Your identity will work with either. Which realm does foo.example.net belong to? Evil.com would be delighted if they could convince you that it belonged to their realm. They'd also be delighted if they could MITM your connection and tell you that it belonged to evil.com and have you believe it. Today, we go all the way back to the home server and use EAP channel binding to resolve this. It works, but involves a performance penalty. There are policy-related concerns beyond that. We've been talking about policy based on gss-acceptor-host-name as well as a currently-moonshot-specific concept called community. Community can be thought of as a sub-federation governing policy rules. Currently we've been assuming the EAP server could apply policy like this. Are we comfortable delegating all that to the visited realm? There are privacy concerns related to realm discovery. Typically when I try fast reauthentication with a service, I will expose my home realm. Indicating that you have an identity in a particular realm is a privacy-sensitive decision. It's something users often consent to, but it does have privacy implications. It also triggers another privacy disclosure. Then, the infrastructure, possibly including the home EAP server, learns that a given user chooses to access a given service. In cases where the client knows the acceptor realm name, it might be reasonable to assume that two services in the same acceptor realm are in the same realm for fast re-reauthentication. In practice, though we find clients basically never know the realm name. (gss-acceptor-realm-name specified by the client proves less useful than we anticipated when we wrote the spec in existing deployments) There are two solutions that have been discussed: Alejandro's draft on using ERP. Advantages: * Most consistent with the existing model * There's some documentation * He's working on it. Needed standardization: * Extend RFC 7055 to support ERP. He's doing that. * Extend ERP to support EAP channel bindings. This proves kind of tricky because it's not clear that you'd trust the visited domain to actually validate channel bindings. If you force ERP back to the home domain, you remove much of the value. * Add ERP RADIUS support. So far only defined for diameter Disadvantages: * RADIUS servers aren't going to support ERP today * Requires RADIUS to maintain key state on all active authentication sessions * Requires good EMSK key handling. * Not clear how to handle server authentication. Need to understand how the key hierarchy really works to evaluate this. Need to consider how this interacts with channel binding. Kerberos Approach Advantages: * An RFC 7055 implementation is likely to have an RFC 4121 implementation around. * We already have proof-of-concept code for the single server case * Kerberos lets the client maintain state; RADIUS would not need to maintain per-session state. * If you solve the realm discovery problem, Kerberos naming is close enough to ABFAb naming that you can avoid channel bindings and solve server authentication. What needs doing: * Specify the protocol * Define some sort of agent that gets the initial server its key and the user a TGT. My preferred embodyment of this is EAP preauthentication, but doing that is probably too complex for available energy * Implement the agent and expand the existing code Disadvantages: * An extra round trip over ERP. It will be a round trip entirely within the visited domain. * The agent to get the TGT is kind of tricky and might need to involve changes or software running on the KDC. * No one is working on this. I'd like to see if we can make some progress on the hard problems of realm discovery and policy that all solutions to this problem will have in common. --Sam _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
