Subject: [abfab] Implementation concern: acceptor name response in extensions state and realm

From: Sam Hartman <[email-masked]>
Date: Sat, 22 Sep 2012 01:08:34 -0400

Hi.
Luke discovered  a bit of a problem.
Jim proposed that acceptors echo back their name rather than simply
relying on the  name match in channel bindings.
The intent is to prevent  a malicious actor from being able to connect
one GSS-EAP peer to another in a situation where  channel binding is not
enforced properly.
That is, we want man-in-the-middle defense always even if we're not
going to get malicious NAS defense because channel binding is not
happening.

The issue is that the initiator and/or acceptor may not know the
acceptor's realm yet.

My recommended implementation strategy is that if the realm name  is
present on both the initiator and acceptor it must match.
Luke notes that it is easier to compare ignoring the realm.
I'm concerned that for some realm-based services that might allow
substitution of one realm for another.

Either way, I think it's probably too late in the process to do
anything about this in terms of spec text.
This will probably be our first Erato.
However I'd like to get community input on what implementations should
do.

---

From: Luke Howard <[email-masked]>
Date: Sat, 22 Sep 2012 15:19:04 +1000

> relying on the  name match in channel bindings.

Your recommended implementation strategy (ignore realm if absent on either side) is easy to implement, no problem there.

In the case of hostname (or more generally, SPN) aliases, then the initiator will fail if the acceptor returns its canonical service principal name, because it has no way of validating one against the other (a simple comparison may fail and the canonicalisation logic belongs on the server side).

(Historical anecdote: between W2K and W2K3 Microsoft changed the behaviour of the canonicalize KDC option in a TGS-REQ so that it would effectively be ignored, i.e. not canonicalize the service principal name in the response.)

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Sat, 22 Sep 2012 02:30:38 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> In the case of hostname (or more generally, SPN) aliases, then
    Luke> the initiator will fail if the acceptor returns its canonical
    Luke> service principal name, because it has no way of validating
    Luke> one against the other (a simple comparison may fail and the
    Luke> canonicalisation logic belongs on the server side).

Right.
That's why the initiator is recommended to send its preferred name in
the initial state.

Actually, perhaps  a better implementation strategy is for the acceptor
to look at what the initiator sends, see if it likes that, and if so,
return exactly that name in extensions state.

If the acceptor doesn't have a good handle on its own aliases, it's
probably better that it not return a response in extensions state (it
has that option).

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 22 Sep 2012 15:44:10 -0700

I am having a problem understanding what is being said here.

The case that we are in here is

1.  The initiator knows the realm it wants the acceptor to be in, but it
does not tell the acceptor that
2.  The acceptor does not know which of multiple realms the initiator wants
to connect to.

If the initiator does not know the realm of the acceptor, then it does not
matter what realm is returned by the acceptor.  
If the initiator tells the realm to the acceptor, then it should always know
what to send back.

If the acceptor returns a different realm that it gives to the IdP, then
channel binding would fail or the initiator would fail.  As long as the
acceptor returns a consistent value then there should not be any problem.

If the acceptor does not return a realm, but gives one to the channel
binding, then a channel binding failure could be expected if it uses the
wrong one.  I don't know that there is any way to say that we should send
multiple different realms to the IdP to say that I could be any of the
following.

What problem is being solved by your proposed errata?

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Friday, September 21, 2012 10:09 PM
> To: [email-masked]
> Subject: [abfab] Implementation concern: acceptor name response in
> extensions state and realm
> 
> 
> Hi.
relying
> on the  name match in channel bindings.
> The intent is to prevent  a malicious actor from being able to connect one
> GSS-EAP peer to another in a situation where  channel binding is not
> enforced properly.
> That is, we want man-in-the-middle defense always even if we're not going
> to get malicious NAS defense because channel binding is not happening.
> 
acceptor's
> realm yet.
> Either way, I think it's probably too late in the process to do anything
about
> this in terms of spec text.
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Luke Howard <[email-masked]>
Date: Sun, 23 Sep 2012 10:57:53 +1000

> probably better that it not return a response in extensions state (it

OK, this makes sense.

The client-not-knowing-the-realm thing can be handled as both Sam and Jim suggested, and I've updated the Moonshot implementation to reflect this.

-- Luke