Subject: [abfab] ABFAb and Fast Reauthentication

From: Sam Hartman <[email-masked]>
Date: Wed, 12 Nov 2014 21:00:16 -0500

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

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 14 Nov 2014 07:22:33 -1000

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ó:
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab