Hi Sam,
thanks for summarizing the discussion. We need to think about these
aspects you've mentioned, and will provide feedback during the next weeks.
Regarding the Kerberos-based approach, would it be possible to get a
more detailed description? I think I have a good idea of how it works
when it is the RP the one that generates the ST, but I'd like to know
more about agent you mention, and how it would interact with the end
user and the KDC to provide the former with a TGT.
Finally, as a preliminary thought, ERP keys already include the RP's
realm during the derivation process. That means that they should provide
something similar to a channel binding, don't they?
The ERP derivation process is as follows.
1. EMSK -> DSRK. Performed by end user and home AAA. It involves RP
realm's name in the derivation process.
2. DSRK -> DS-rRK. Performed by end user and home AAA, and distributed
to the AAA proxy.
3. DS-rRK -> rMSK. Performed by end user and AAA proxy, and distributed
to the RP. It is used as the MSK.
Therefore the rMSK includes the RP's realm into its derivation process.
If the end user or the home AAA server differ on their view, the keys
will differ as well, and the communication will fail.
Regards,
Alejandro
El 12/11/14 a las 16:00, Sam Hartman escribió:
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
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
