Subject: Re: holder of key for encrypted subject
From: Josh Howlett <[email-masked]>
To: [email-masked]
Date: Fri, 30 Apr 2010 16:08:00 +0100

>     >> Josh's idea to get around the RADIUSS MTU issue is to include a
>     >> compressed authentication assertion in the RADIUS response and
>     >> for the SP to make a SAML attribute query.  The authentication
>     >> assertion would effectively serve as a token for the 
> SP to prove
>     >> it was entitled to attributes surrounding the subject.
> 
>     Scott> That's a bit of a complex approach and requires 
> implementing
>     Scott> WS-Security-based SOAP queries, which is not something I'd
>     Scott> take on without a really good reason.
> 
> How does authentication for attribute queries actually happen 
> then today?

I think we might have our wires crossed slightly. My suggestion was that
the SP uses the Subject from the assertion within the AttributeQuery, as
normally happens with attribute query, not the entire assertion. I agree
with Scott that using an assertion as a token would be rather complex.

However, I think I initially misunderstood Sam's proposal. I assumed
that the attribute query and response would be "signed" using the key
sent to the SP over RADIUS.

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Fri, 30 Apr 2010 15:12:54 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> There's another way though.  The IDP and RADIUS server already share a
> secret. Use that key and a secure key derivation function (NIST SP
> 800-56?) to construct the key.  That way you don't actually need to
> spend any bytes on key transport.

Right, that makes sense.

> I probably prefer explicit key transport because it's easier to see what
> its security properties are.  The KDF is fine though from a security
> standpoint and definitely avoids any concern about length of identifiers.

A key + an alg OID or something compact would probably fit without much
trouble, I just wanted to note the possibility.

-- Scott

Date: Fri, 30 Apr 2010 15:03:03 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

If we run into size limits, there are several approaches.  Note that we
need to trasport between 16 and 32 bytes of key material plus an
algorithm identifier if we want to transport the key.

There's another way though.  The IDP and RADIUS server already share a
secret.  Use that key and a secure key derivation function (NIST SP
800-56?) to construct the key.  That way you don't actually need to
spend any bytes on key transport.

I probably prefer explicit key transport because it's easier to see what
its security properties are.  The KDF is fine though from a security
standpoint and definitely avoids any concern about length of
identifiers.

--Sam

Date: Fri, 30 Apr 2010 14:54:46 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> What I think we can take away from this is that
>
> 1) RADIUS needs to be able to express this at the cross -domain level
> (trivially true)
> 2) Our architecture needs to permit deployments where this distinction
> is reflected into separate SP SAML identities.

That's my preference, yes.

Thanks,
-- Scott

Date: Fri, 30 Apr 2010 14:51:52 +0100
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

> In the scope of the beyond web use case, I'm not concerned 
> about SPs needing metadata for the IDP; only for the IDP to 
> be provisioned with information about each SP.

Why aren't you concerned about SPs needing metadata for the IdP for the
beyond web SSO use cases?

> I think we should carefully explore how true that is for the 
> use cases motivating beyond web SSO.  Is it really true for 
> the outsourcing providers that servers are registered at the 
> individual host level?

It might be, but it doesn't have to be. You can abstract a host of hosts
behind a single SAML SP entity.

> That seems surprising to me.  Also, I think both for the HPC 
> and outsourcing use case, allowing each SP to dynamically 
> manage their servers will be important.

I agree. It's just not the way that we interact with customers today (of
course, that's not a reason not to change).

> A third observation that comes to me: the complexity of all 
> of this argues for doing as much as we can in the RADIUS 
> exchange so that we do not need multiple trust infrastructures.

Right. Ultimately, that's the point of the "scalable trust" use-case
category: to seek a single mechanism to support the exchange of claims
about things in different types of systems, without getting distracted
by the idiosyncracies of the systems in question.

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Fri, 30 Apr 2010 14:51:20 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

Scott> As organizations get large, this distinction matters more,
Scott> and as they get small, the benefits of the gateway decrease.
>> Ah.  I was sort of assuming you'd want to release to "blah mail
>> servers," or to "Quux's HPC cluster."  The rationale is that I
>> might be willing to release far more information to MIT's HPC
>> cluster with which I have a business arrangement than I would to
>> a random dorm computer at MIT.

Scott> Yes, that's my point. I can't do that meaningfully if the
Scott> only distinction that exists is behind the RADIUS server at
Scott> MIT. I can trust the RADIUS server to do the right thing, but
Scott> I have no direct influence.

What I think we can take away from this is that

1) RADIUS needs to be able to express this at the cross -domain level
(trivially true)
2) Our architecture needs to permit deployments where this distinction
is reflected into separate SP SAML identities.

--Sam

Date: Fri, 30 Apr 2010 14:02:34 +0100
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

Sam,

> Josh and Scott have been assuming that we would have the same 
> level of provisioning today for relying parties.
...
> I also don't think it is desirable to couple the Moonshot 
> trust management tightly enough to the beyond SSO stuff in 
> order to require the trust management to make this work.

Agreed. I think Scott and I were going further, in the sense that we
shouldn't have a coupling with /any/ particular trust management scheme.

I also agree that we should seek optimisations to facilitate deployment
(but in seeking optimisations, we should be careful not to neglect the
composability of the architecture).

> I wonder whether we could provision a key that is conveyed to 
> the IDP in the subject with the RADIUS exchange.  That way, 
> if the SP didn't have other credentials to use, it could 
> authenticate as the holder of that key.  The key could be 
> transported to the SP in a RADIUS attribute, and transported 
> to the IDP in the subject.

Interesting idea! Some observations:

First, the provisioning that we use today isn't just about key
provisioning. It is also used to provide entities with information about
the location of service endpoints; for example, the URI needed by the SP
to approach the IdP with an attribute query. We normally provision this
information alongside the key(s) in metadata. We could consider an
approach whereby the entities concerned obtain this metadata from each
other directly, and establish trust in the metadata by extending your
mechanism to supply a proof. Unfortunately this mechanism would not
support the current means by which we (as federation operators) make
statements about entities that are frequently used by other entities to
inform trust decisions (such as the LoA supported by an IdP). We could
change the way in which we (as federation operators) make these
statements, but this would require distributing signed assertions that
contain these claims to the entity operators for them to include in
their metadata. This would necessitate some fairly signicant changes to
operational practise.

I note that Moonshot trust management, when applied to SAML metadata,
also implies significant changes to operational practise that might not
be dissimilar to that described above, and so it might be worth
exploring whether this is actually a useful transition step. As in all
things related to trust management, I need to think this over some more.

My second observation is that this reduces operational complexity at the
expense of additional implementation effort (I don't think it would be
significant effort, and I will immediately defer to Scott's opinion!).
However, the initial deployment community that is the target of the
proof-of-concept already bears the costs of operating distinct RADIUS
and SAML systems, and so this optimisation doesn't really help. I
understand, however, that it would help other communities.

best regards, josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Fri, 30 Apr 2010 12:33:42 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

>     Scott> Even if you really did imitate Kerberos and send the SP both
>     Scott> the key and the key encrypted to the IdP, what would be the
>     Scott> mechanism by which the latter ends up back at the IdP?
>
>
> I can see a couple of options.
>
> 1) The RADIUS server generates metadata and feeds it to the IDP

True, I hadn't considered that.

> 2) What I recommend we implement: the key is included in the encrypted
> subject.

Maybe, but I don't think it would be an EncryptedID in the SAML sense of the
construct, I don't think there's a way to embed a key like this. There *is*
a way via holder of key assertions, which is why I assumed that's what you
meant literally.

You can create encrypted, MAC'd strings that carry data to the IdP via
transient NameIDs, but there are some size limits. We used to encrypt the
principal name, expiration time, SP name, and a MAC, and they were ok, but
not that far from the limit.

Of course, a custom Format can be used for a larger NameID to get around the
limit, but the limit's there for practical reasons (logging/auditing, that
kind of thing).

> As far as the acceptor is concerned, we're saying that as a local
> matter, the RADIUS server and IDP need to make sure that the IDP knows
> the key somehow.  That doesn't allow us to escape specifying a mechanism
> so you can manage to have an IDP of your choice work with an arbitrary
> RADIUS server, but it does minimize the number of parties in that
> mechanism.

Yes, I just wasn't sure whether you had a particular strategy defined that I
wasn't seeing, or were deferring the details.

-- Scott

Date: Fri, 30 Apr 2010 12:21:03 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

>     Scott> As organizations get large, this distinction matters more,
>     Scott> and as they get small, the benefits of the gateway decrease.
>  Ah.  I was sort of assuming you'd want to release to "blah mail
> servers," or to "Quux's HPC cluster."  The rationale is that I might be
> willing to release far more information to MIT's HPC cluster with which
> I have a business arrangement than I would to a random dorm computer at
> MIT.

Yes, that's my point. I can't do that meaningfully if the only distinction
that exists is behind the RADIUS server at MIT. I can trust the RADIUS
server to do the right thing, but I have no direct influence.

But queries of course never provide anything but an illusion of such control
anyway, since all you get is the key and no control over where the data is
actually sent back to.

And location-based control on the front channel is contingent on vetting of
locations, and most federations devolve that to organizational control
anyway. But I think in terms of architecturally what's possible vs. what's
true in common practice.

-- Scott

Date: Fri, 30 Apr 2010 12:12:29 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

>> In this instance, I think the gateway significantly helps trust.
>> It means that the credential that the IDP knows about is housed
>> on a fairly trusted box rather than say a bunch of edge servers.
>> It means that the SP domain has much better options for dealing
>> with credential rotation and key compromise for the credentials
>> that are on the edge servers.

Scott> Yes, but it also means that as an IdP I'm effectively
Scott> releasing data not to the edge servers hosting actual
Scott> resources or services but to a central system that may have
Scott> nothing to do with my users, or the use case. And I argue as
Scott> a result that the SP should never be portrayed as anything
Scott> other than "Ohio State" or "MIT" or "Microsoft", or whatever
Scott> the case may be.

Scott> As organizations get large, this distinction matters more,
Scott> and as they get small, the benefits of the gateway decrease.

Ah.  I was sort of assuming you'd want to release to "blah mail
servers," or to "Quux's HPC cluster."  The rationale is that I might be
willing to release far more information to MIT's HPC cluster with which
I have a business arrangement than I would to a random dorm computer at
MIT.

--Sam

Date: Fri, 30 Apr 2010 12:04:26 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> In this instance, I think the gateway significantly helps trust.  It
> means that the credential that the IDP knows about is housed on a fairly
> trusted box rather than say a bunch of edge servers.  It means that the
> SP domain has much better options for dealing with credential rotation
> and key compromise for the credentials that are on the edge servers.

Yes, but it also means that as an IdP I'm effectively releasing data not to
the edge servers hosting actual resources or services but to a central
system that may have nothing to do with my users, or the use case. And I
argue as a result that the SP should never be portrayed as anything other
than "Ohio State" or "MIT" or "Microsoft", or whatever the case may be.

As organizations get large, this distinction matters more, and as they get
small, the benefits of the gateway decrease.

> We could do this all end-to-end, but I think it would actually decrease
> the robustness and security of the system.  If I'm wrong , then we can
> probably simplify things a lot by treating it end-to-end.

One of the differences I'll grant is that because of the dependency on
RADIUS regardless, this is not something that a run of the mill developer
can simply instantiate without regard for his broader organizational
infrastructure. That's a concern to me, but it's not a problem that your
suggestion exacerbates, I admit.

-- Scott

Date: Fri, 30 Apr 2010 11:54:23 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

Scott> So does assigning everything its own IP address, but there
Scott> are understood to be benefits. Gateways harm trust,
Scott> accountability, privacy, etc.

In this instance, I think the gateway significantly helps trust.  It
means that the credential that the IDP knows about is housed on a fairly
trusted box rather than say a bunch of edge servers.  It means that the
SP domain has much better options for dealing with credential rotation
and key compromise for the credentials that are on the edge servers.

>> This discussion is reenforcing my belief that we're far better
>> off if everything happens in the RADIUS exchange.

Scott> Is it the local RADIUS hop that proves its identity
Scott> cross-domain then? And it's left to that system to decide
Scott> which GSS acceptors are allowed to logically act in the
Scott> capacity that the RADIUS system represents to the outside
Scott> world?

Yes.  There's some discussion of this in the feasibility analysis.

We could do this all end-to-end, but I think it would actually decrease
the robustness and security of the system.  If I'm wrong , then we can
probably simplify things a lot by treating it end-to-end.

Date: Fri, 30 Apr 2010 11:48:52 +0100
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Re: Probably no audio archive for the bar bof

> I was hoping to post a link to the IETF bar bof audio. 
> Unfortunately, as best I can tell,while the audio was 
> streamed, only normal sessions were archived.
> So, it looks like we will not have an audio archive for te bar bof.

I was listening on iTunes. I am probably clutching at straws but does
anyone know if iTunes caches streams locally? A quick Google search
suggests that I am, indeed, straw-clutching but I might not be using the
right search terms.

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Fri, 30 Apr 2010 11:46:52 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

Scott> I know that's the underlying exchange, but you were
Scott> describing an in-band communication of the proof key from
Scott> RADIUS to the IdP
>> yes.

Scott> But as I understand it, the IdP isn't supposed to have to
Scott> know anything about RADIUS, so outside of using a holder of
Scott> key assertion, how else would it be done?

Scott> Even if you really did imitate Kerberos and send the SP both
Scott> the key and the key encrypted to the IdP, what would be the
Scott> mechanism by which the latter ends up back at the IdP?

I can see a couple of options.

1) The RADIUS server generates metadata and feeds it to the IDP

2) What I recommend we implement: the key is included in the encrypted
subject.

As far as the acceptor is concerned, we're saying that as a local
matter, the RADIUS server and IDP need to make sure that the IDP knows
the key somehow.  That doesn't allow us to escape specifying a mechanism
so you can manage to have an IDP of your choice work with an arbitrary
RADIUS server, but it does minimize the number of parties in that
mechanism.

Date: Fri, 30 Apr 2010 11:36:55 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

>     Scott> I know that's the underlying exchange, but you were
>     Scott> describing an in-band communication of the proof key from
>     Scott> RADIUS to the IdP
> yes.

But as I understand it, the IdP isn't supposed to have to know anything
about RADIUS, so outside of using a holder of key assertion, how else would
it be done?

Even if you really did imitate Kerberos and send the SP both the key and the
key encrypted to the IdP, what would be the mechanism by which the latter
ends up back at the IdP?

I thought the general flow of the SAML would be:

- RADIUS sends back authn assertion to SP along with key it should use.
- SP performs query to IdP signed with key using std SOAP binding.

So how does the key binding get communicated to the IdP, which isn't party
to the first step?

-- Scott

Date: Fri, 30 Apr 2010 11:30:32 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

>     Scott> My suggestion is to avoid bringing the end to end vs. gateway
>     Scott> discussion into the architecture. If people want gateways,
>     Scott> they can proxy the interactions as they choose.
>
> I have a couple of concerns about that approach.
>
> First, we're building an implementation not just a standard.  So, I
> don't think we can escape it.

Well, I escape it in Shibboleth by building for end to end and letting
people that want gateways get them somewhere else, but that's my bias.

> Secondly, I don't see any reason to believe that the gateway and GSS
> acceptor are guaranteed to be from the same vendor.  At least as the
> IETF looks at things, that means you need a spec to get interoperability.

Yes, but that's not a lot of work to specify, at least with regard to SOAP
queries.

> Finally, I think ignoring this will increase deployment complexity
> significantly.

So does assigning everything its own IP address, but there are understood to
be benefits. Gateways harm trust, accountability, privacy, etc.

> This discussion is reenforcing my belief that we're far better off if
> everything happens in the RADIUS exchange.

Is it the local RADIUS hop that proves its identity cross-domain then? And
it's left to that system to decide which GSS acceptors are allowed to
logically act in the capacity that the RADIUS system represents to the
outside world?

-- Scott

Date: Fri, 30 Apr 2010 11:24:24 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

>> Ah, I think I might have been two precise in my terminology.
>> server TLS plus xml signature on the query with the SP learning
>> the key to use for a MAC from the RADIUS exchange falls within
>> what I was talking about.

Scott> I know that's the underlying exchange, but you were
Scott> describing an in-band communication of the proof key from
Scott> RADIUS to the IdP
yes.

Scott> via a holder of key assertion, which is
Scott> where the complexity comes in.

Ah, no.  I only intended to draw an analogy to holder of key.  I was
just planning to use RADIUS's existing "mechanisms" [1] for sending the
key.

[1] They are fairly primitive.

Date: Fri, 30 Apr 2010 11:21:49 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> Ah, I think I might have been two precise in my terminology.  server TLS
> plus xml signature on the query with the SP learning the key to use for
> a MAC from the RADIUS exchange falls within what I was talking about.

I know that's the underlying exchange, but you were describing an in-band
communication of the proof key from RADIUS to the IdP via a holder of key
assertion, which is where the complexity comes in.

My question remains, though, how does the SP prove that it should receive
that key from the RADIUS infrastructure? I thought it did so by
authenticating itself with something that the IdP-affiliated RADIUS would
trust. That amounts to the same issue with the SP having credentials trusted
cross-domain.

I'm sure it's just my RADIUS and EAP ignorance here.

-- Scott

Date: Fri, 30 Apr 2010 11:21:33 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

>> From a SAML standpoint this is true.  I'm concerned though about
>> how this works at an implementation level with GSS.  In
>> particular, it seems very undesirable to force all the
>> cross-domain credentials out to endpoints.

Scott> My suggestion is to avoid bringing the end to end vs. gateway
Scott> discussion into the architecture. If people want gateways,
Scott> they can proxy the interactions as they choose.

I have a couple of concerns about that approach.

First, we're building an implementation not just a standard.  So, I
don't think we can escape it.

Secondly, I don't see any reason to believe that the gateway and GSS
acceptor are guaranteed to be from the same vendor.  At least as the
IETF looks at things, that means you need a spec to get
interoperability.

Finally, I think ignoring this will increase deployment complexity
significantly.

This discussion is reenforcing my belief that we're far better off if
everything happens in the RADIUS exchange.

Date: Fri, 30 Apr 2010 11:17:07 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

>> How does authentication for attribute queries actually happen
>> then today?
Scott> Commercially, you'll see TLS, signing, and even basic-auth
Scott> (commercial products tending to care only about point to
Scott> point federation).

Scott> The SP supports a few esoteric methods, but the two that are
Scott> actually widely supported are TLS or XML Signatures over the
Scott> SAML request in some combination, with the trust layer based
Scott> on the metadata corresponding to the SAML message issuer.

Scott> In practice, it's usually mutual TLS, but client signature +
Scott> server TLS would be the other one that you'd see for cases
Scott> where the TLS doesn't terminate at the IdP.

Ah, I think I might have been two precise in my terminology.  server TLS
plus xml signature on the query with the SP learning the key to use for
a MAC from the RADIUS exchange falls within what I was talking about.

--Sam

Date: Fri, 30 Apr 2010 11:10:41 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> How does authentication for attribute queries actually happen then today?

Commercially, you'll see TLS, signing, and even basic-auth (commercial
products tending to care only about point to point federation).

The SP supports a few esoteric methods, but the two that are actually widely
supported are TLS or XML Signatures over the SAML request in some
combination, with the trust layer based on the metadata corresponding to the
SAML message issuer.

In practice, it's usually mutual TLS, but client signature + server TLS
would be the other one that you'd see for cases where the TLS doesn't
terminate at the IdP.

We implemented delegation support at the IdP via an extension that supports
client TLS as a key proof for a holder of key assertion in a WS-Security
header, but it's handled only in the extension for a single profile we
needed and hasn't been generalized out to the IdP's security layer for use
with other profiles.

-- Scott

Date: Fri, 30 Apr 2010 11:04:02 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> From a SAML standpoint this is true.  I'm concerned though about how
> this works at an implementation level with GSS.  In particular, it seems
> very undesirable to force all the cross-domain credentials out to
> endpoints.

My suggestion is to avoid bringing the end to end vs. gateway discussion
into the architecture. If people want gateways, they can proxy the
interactions as they choose.

-- Scott

Date: Fri, 30 Apr 2010 10:51:08 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

>> Josh's idea to get around the RADIUSS MTU issue is to include a
>> compressed authentication assertion in the RADIUS response and
>> for the SP to make a SAML attribute query.  The authentication
>> assertion would effectively serve as a token for the SP to prove
>> it was entitled to attributes surrounding the subject.

Scott> That's a bit of a complex approach and requires implementing
Scott> WS-Security-based SOAP queries, which is not something I'd
Scott> take on without a really good reason.

How does authentication for attribute queries actually happen then
today?

Date: Fri, 30 Apr 2010 10:49:00 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

Scott> Furthermore, in the query case specifically, offloading the
Scott> query to a shared system that handles the load for a range of
Scott> actual app services is fairly simple. That's merely a twist
Scott> on the usual commercial model of federation, which is to have
Scott> a gateway visible to the IdPs and everything else implemented
Scott> with proprietary SSO behind that.

Again, to standardize this with GSS, and more particularly to implement
this, we need to actually specify all the components.

Date: Fri, 30 Apr 2010 10:47:06 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

>>>>> "Scott" = Scott Cantor <[email-masked]> writes:

Scott> An SP is a wholly logical construct. The mapping to physical
Scott> systems is entirely arbitrary. It's also not based on
Scott> hostnames like SSL is. Hostnames only come into play when
Scott> they have to, to enforce security provisions that are
Scott> relevant to the IdP, such as with web site endpoints.

Date: Fri, 30 Apr 2010 10:37:17 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

> Josh's idea to get around the RADIUSS MTU issue is to include a
> compressed authentication assertion in the RADIUS response and for the
> SP to make a SAML attribute query.  The authentication assertion would
> effectively serve as a token for the SP to prove it was entitled to
> attributes surrounding the subject.

That's a bit of a complex approach and requires implementing
WS-Security-based SOAP queries, which is not something I'd take on without a
really good reason.

In SAML, that's essentially delegation. We know how to do it and we have
code that does a big chunk of it, but it's not implemented for securing
attribute queries on either end right now.

> Josh and Scott have been assuming that we would have the same level of
> provisioning today for relying parties. I'm very uncomfortable with that.

Well, for reasons I stated in the other message, this comes up a lot but I
think is largely a non-issue in practice.

> In order to support our use cases I think it is critical that SPs should
> only need to be provisioned within their own domain, not globally.

An SP is a wholly logical construct. The mapping to physical systems is
entirely arbitrary. It's also not based on hostnames like SSL is. Hostnames
only come into play when they have to, to enforce security provisions that
are relevant to the IdP, such as with web site endpoints.

> For example, I think we'd want to say something roughly like "Google is
> permitted to run mail servers," globally, "Google's mail servers get the
> e-mail address of XYZ's users," in XYZ's attribute release policies, but
> only Google needs to know what Google's mail servers actually are.

That just means they all have to share one SAML identity and some set of
credentials bound to that identity.

> I wonder whether we could provision a key that is conveyed to the IDP in
> the subject with the RADIUS exchange.  That way, if the SP didn't have
> other credentials to use, it could authenticate as the holder of that
> key.  The key could be transported to the SP in a RADIUS attribute, and
> transported to the IDP in the subject.

Isn't it the case that the RADIUS exchange is such that the SP is being
authenticated anyway? I thought the whole system was predicated on the SP
being trusted to participate in the exchange. If it's trusted, then it has a
credential anyway, right?

> So, under this model, the subject would be very similar to a Kerberos
> ticket; in an encrypted structure it would include:

Notwithstanding my questions, yes, it's possible to do most of that with
SubjectConfirmation. But I think the implementation complexity coupled with
the questionable benefits makes it a bad idea.

Plus which, I thought you were arguing for using transient IDs that would
act as pesudo-bearer credentials anyway?

-- Scott

Date: Fri, 30 Apr 2010 10:34:03 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

>>>>> "Josh" = Josh Howlett <[email-masked]> writes:

>> In the scope of the beyond web use case, I'm not concerned about
>> SPs needing metadata for the IDP; only for the IDP to be
>> provisioned with information about each SP.

Josh> Why aren't you concerned about SPs needing metadata for the
Josh> IdP for the beyond web SSO use cases?

Not entirely sure.  Some of it is an assumption that I'm making that
there are more SPs than IDPs.

>> I think we should carefully explore how true that is for the use
>> cases motivating beyond web SSO.  Is it really true for the
>> outsourcing providers that servers are registered at the
>> individual host level?

Josh> It might be, but it doesn't have to be. You can abstract a
Josh> host of hosts behind a single SAML SP entity.

This is much less true for GSS.  AT least, GSS tends to be aware of the
individual host.

Also, from a security standpoint, I'm more comfortable with the
cross-domain credentials living on  domain AAA servers than on each SP.

--Sam

Date: Fri, 30 Apr 2010 10:20:23 -0400
From: Scott Cantor <[email-masked]>
To: [email-masked]
Organization: The Ohio State University

>> I think we should carefully explore how true that is for the
>> use cases motivating beyond web SSO.  Is it really true for
>> the outsourcing providers that servers are registered at the
>> individual host level?
>
> It might be, but it doesn't have to be. You can abstract a host of hosts
> behind a single SAML SP entity.

Correct. It's also not necessarily even "host"-based when you're talking
about non-web services.  There may *be* hosts of course, but those hosts may
not be addressable in the same way and the metadata may not need to care
what they are.

What ultimately matters for queries is generally an identity and a
credential (a key). The reason for using metadata in those cases and not
just PKI are varied and I won't waste the time on it here.

Furthermore, in the query case specifically, offloading the query to a
shared system that handles the load for a range of actual app services is
fairly simple. That's merely a twist on the usual commercial model of
federation, which is to have a gateway visible to the IdPs and everything
else implemented with proprietary SSO behind that.

>> That seems surprising to me.  Also, I think both for the HPC
>> and outsourcing use case, allowing each SP to dynamically
>> manage their servers will be important.
>
> I agree. It's just not the way that we interact with customers today (of
> course, that's not a reason not to change).

Most of the time server farms like that are sitting behind load balanced
names that don't change often anyway. So even on the front channel, it's not
*that* big a deal. And even if the names do change, as long as the metadata
processing is automated, all the SP does is make their registration changes
with a federation and wait a day. It just isn't that big a deal. It's a
common perception that it's a big deal.

-- Scott

Date: Fri, 30 Apr 2010 09:11:21 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: holder of key for encrypted subject

>>>>> "Josh" = Josh Howlett <[email-masked]> writes:

>> I wonder whether we could provision a key that is conveyed to the
>> IDP in the subject with the RADIUS exchange.  That way, if the SP
>> didn't have other credentials to use, it could authenticate as
>> the holder of that key.  The key could be transported to the SP
>> in a RADIUS attribute, and transported to the IDP in the subject.

Josh> Interesting idea! Some observations:

Josh> First, the provisioning that we use today isn't just about key
Josh> provisioning. It is also used to provide entities with
Josh> information about the location of service endpoints; for
Josh> example, the URI needed by the SP to approach the IdP with an
Josh> attribute query. We normally provision this information
Josh> alongside the key(s) in metadata. We could consider an
Josh> approach whereby the entities concerned obtain this metadata
Josh> from each other directly, and establish trust in the metadata
Josh> by extending your mechanism to supply a proof. Unfortunately
Josh> this mechanism would not support the current means by which we
Josh> (as federation operators) make statements about entities that
Josh> are frequently used by other entities to inform trust
Josh> decisions (such as the LoA supported by an IdP). We could
Josh> change the way in which we (as federation operators) make
Josh> these statements, but this would require distributing signed
Josh> assertions that contain these claims to the entity operators
Josh> for them to include in their metadata. This would necessitate
Josh> some fairly signicant changes to operational practise.

In the scope of the beyond web use case, I'm not concerned about SPs
needing metadata for the IDP; only for the IDP to be provisioned with
information about each SP.

In the case of the trust management use cases  I think  that this sort
of exploration is very valuable.
Josh> My second observation is that this reduces operational
Josh> complexity at the expense of additional implementation effort
Josh> (I don't think it would be significant effort, and I will
Josh> immediately defer to Scott's opinion!).  However, the initial
Josh> deployment community that is the target of the
Josh> proof-of-concept already bears the costs of operating distinct
Josh> RADIUS and SAML systems, and so this optimisation doesn't
Josh> really help. I understand, however, that it would help other
Josh> communities.

I think we should carefully explore how true that is for the use cases
motivating beyond web SSO.  Is it really true for the outsourcing
providers that servers are registered at the individual host level?
That seems surprising to me.  Also, I think both for the HPC and
outsourcing use case, allowing each SP to dynamically manage their
servers will be important.

A third observation that comes to me: the complexity of all of this
argues for doing as much as we can in the RADIUS exchange so that we do
not need multiple trust infrastructures.

--Sam

Date: Fri, 30 Apr 2010 07:10:36 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: holder of key for encrypted subject

Scott, Josh and I have been discussing the SAML interactions between the
RADIUS server and IDP.

Josh's idea to get around the RADIUSS MTU issue is to include a
compressed authentication assertion in the RADIUS response and for the
SP to make a SAML attribute query.  The authentication assertion would
effectively serve as a token for the SP to prove it was entitled to
attributes surrounding the subject.

Josh and Scott have been assuming that we would have the same level of
provisioning today for relying parties.
I'm very uncomfortable with that.

In order to support our use cases I think it is critical that SPs should
only need to be provisioned within their own domain, not globally.  For
example, I think we'd want to say something roughly like "Google is
permitted to run mail servers," globally, "Google's mail servers get the
e-mail address of XYZ's users," in XYZ's attribute release policies, but
only Google needs to know what Google's mail servers actually are.

I also don't think it is desirable to couple the Moonshot trust
management tightly enough to the beyond SSO stuff in order to require
the trust management to make this work.

I wonder whether we could provision a key that is conveyed to the IDP in
the subject with the RADIUS exchange.  That way, if the SP didn't have
other credentials to use, it could authenticate as the holder of that
key.  The key could be transported to the SP in a RADIUS attribute, and
transported to the IDP in the subject.

So, under this model, the subject would be very similar to a Kerberos
ticket; in an encrypted structure it would include:
* identifier for subject known to IDP
* identifier for SP
* Any group information the RADIUS server needs to community to know
what attribute release policy the subject is in
* Key that has been shared with the SP
* Expiration time

--Sam

Date: Fri, 30 Apr 2010 06:19:41 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Probably no audio archive for the bar bof

I was hoping to post a link to the IETF bar bof audio. Unfortunately, as
best I can tell,while the audio was streamed, only normal sessions were
archived.
So, it looks like we will not have an audio archive for te bar bof.

Date: Wed, 21 Apr 2010 21:08:49 +0100
From: Josh Howlett <[email-masked]>
To: [email-masked]
Subject: Brief update

1. Closure of Phase 1

We have now completed the first major phase of Project Moonshot. This
was in part a technical sanity check, and in part a toe-in-the-water to
test the community's receptiveness of (1) the importance of solving our
use-cases and (2) the approach that we are proposing to addressing
these.

We have satisfied ourselves that the reception to these has been
sufficiently positive to warrant progression to Phase 2.

I would like to thank everyone who has contributed their opinions and
ideas. This feedback has been tremendously useful.

2. Progression to Phase 2

Phase 2 of Project Moonshot begins. In this phase we are focusing on the
planning the implementation of a proof-of-concept test-bed that
demonstrates the use-cases. This phase will run from now until end July
2010. We expect to have a detailed complete project plan by the end of
May.  

We will also be preparing the ground for a new IETF Working Group, which
we feel is the most appropriate vehicle for addressing the problems
under discussion. We definitely do *not* want this to be a "Moonshot"
working group; we think it would be better if the WG were chartered to
consider the general problem of application of federated identity to
non-web protocols, and the range of possible technical approaches.

Phase 2 will close with after the end of IETF 78. If we have satisfied
ourselves that we have sufficient community support, a credible plan,
and the resources to execute it, we expect to move onto Phase 3 which is
when we start to build the rocket.

3. GEANT participation

The GEANT project has agreed to commit some significant resources to
Project Moonshot. This has allowed us to obtain access to some scarce
talents, which is a fantastic development. More on this when the project
plan is complete.

4. More rocket scientists required!

We warmly welcome the participation of other parties. If you or your
organisation has an interest, please drop me a line.

best regards, josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Mon, 19 Apr 2010 21:30:23 +0200
From: Rafa Marin Lopez <[email-masked]>
To: [email-masked]
Subject: EAP over Kerberos

--Apple-Mail-4--807036317
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii

Dear all,

my colleague Gabi and I thought about the idea (see attached slides) of transporting EAP over Kerberos. That is, EAP is used as a pre-authentication method for Kerberos (transported in pa-data field). In other words, Kerberos would act as EAP lower-layer (see slide 3). In this model, KDC is acting as EAP authenticator and can interface with a backend AAA infrastructure. With the key material obtained after EAP authentication (e.g. MSK) it would be possible to generate a shared secret between Kerberos client and KDC.

After thinking about this idea, we realized that moonshot document talked also about the alternative of transporting EAP over Kerberos. That is the reason of discussing this idea in this mailing list.

Moreover, taking into account EAP-GSS, we thought about another alternative (see slide 6). In this alternative, Kerberos uses GSS-API to obtain pre-authentication data. In particular, the GSS TOKEN could carry EAP as EAP-GSS approach specifies.

We would like to share these ideas in order to discuss them in the context of Moonshot. In fact, some discussions have been already happened with Sam and Josh and some possible issues still need discussions: for example, we believe that if KDC acts as EAP authenticator, KDC will have to be stateful.

Thus, any comment is highly appreciated.

Best regards.

--Apple-Mail-4--807036317
Content-Disposition: inline;
filenameêp_over_krb_saml.pdf
Content-Type: application/pdf;
x-unix-mode44;
name="eap_over_krb_saml.pdf"
Content-Transfer-Encoding: base64

--Apple-Mail-4--807036317
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

--Apple-Mail-4--807036317--

Date: Tue, 6 Apr 2010 17:19:45 +0200
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: Feasibility Analysis, Negotiating an EAP method

Sam Hartman wrote:
> There is an additional concern.  At this point in the process, we have
> not learned the identity of the peer.

I don't know the full details of the IEEE EAPoL state machine, but
IIRC, there are provisions for an Access-Point to send an EAP identity
request.  The peer should then respond with an identity that contains a
realm.

>  So, we don't even know what EAP
> server to contact.  So, even ignoring the credentials matching to method
> issue you describe and the problem that RADIUS does not provide the
> information we need described in the paper, we're absolutely stopped by
> the fact that we don't know what party to contact in order to find out
> what EAP methods might be available.

If WiFi roaming groups can use EAP, I don't see why there are any
technical problems here.

Alan DeKok.

Date: Tue, 6 Apr 2010 11:49:36 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Feasibility Analysis, Negotiating an EAP method

>>>>> "Alan" = Alan DeKok <[email-masked]> writes:

Alan> Sam Hartman wrote:
>> There is an additional concern.  At this point in the process, we
>> have not learned the identity of the peer.

Alan>   I don't know the full details of the IEEE EAPoL state
Alan> machine, but IIRC, there are provisions for an Access-Point to
Alan> send an EAP identity request.  The peer should then respond
Alan> with an identity that contains a realm.

At this point in the GSS exchange, we've not committed to using EAP.

At the GSS layer, you can't commit to a particular way of describing the
initiator (peer)'s identity until you've committed to a particular
mechanism.

You're right though that there are no technical problems here.  The
analysis document proposes simply that we need to rethink how GSS deals
with negotiation.  The draft GSS mechanism solves this issue by
requiring the client to commit to using EAP before deciding what EAP
method to use.
At that point, all these issues go away, and the typical EAP solutions
apply.

As I've discussed this issue with members of the GSS community, they
tend to agree that while GSS normally discourages multi-layer
negotiation, that performing a multi-layer negotiation is exactly the
right approach here.  One reason advanced for this is that the
negotiations are with different parties.  The initiator and acceptor
(NAS) decide to use EAP; the peer (initiator) and EAP server decide what
EAP method to use.

--Sam

Date: Tue, 6 Apr 2010 09:27:18 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Feasibility Analysis, Negotiating an EAP method

>>>>> "David" = David Mitton <[email-masked]> writes:

David> Sam, Let me start by saying I do believe you have an issue
David> here.

David> My original objection was to how the problem was described
David> "the NAS needs to know what EAP method to use" Even given
David> some situational license, this is not a NAS problem in
David> general, but with your NAS application.  (and my comment
David> about layering wasn't meant to be a suggestion, but a warning
David> why that would be a bad idea)

Here we're agreed.  All that paragraph is saying is that to implement
GSS-API style negotiation, where before anything else happens, the
acceptor provides a set of mechanisms, the acceptor needs to know what
mechanisms to provide.  Since that part of the acceptor inherently has
to be the NAS, then the NAS would need to know the EAP methods to
implement that strategy.

For a variety of reasons, we both agree that will not work.  Some of the
reasons are stated in the rest of the paragraph in question.  Your
concern about making sure the credentials are appropriate is also a
reason that things might fail.

There is an additional concern.  At this point in the process, we have
not learned the identity of the peer.  So, we don't even know what EAP
server to contact.  So, even ignoring the credentials matching to method
issue you describe and the problem that RADIUS does not provide the
information we need described in the paper, we're absolutely stopped by
the fact that we don't know what party to contact in order to find out
what EAP methods might be available.  I think you and I are agreed that
providing a list of EAP methods to the peer from the NAS before identity
information is exchanged is not a valid technical approach.

--Sam

Date: Mon, 5 Apr 2010 22:44:31 -0400
From: David Mitton <[email-masked]>
To: [email-masked]
Subject: Re: Feasibility Analysis, Negotiating an EAP method

Sam,
Let me start by saying I do believe you have an issue here.

My original objection was to how the problem was described
"the NAS needs to know what EAP method to use"
Even given some situational license, this is not a NAS problem in general,
but with your NAS application.
(and my comment about layering wasn't meant to be a suggestion, but a
warning why that would be a bad idea)

But if I back up a second, I don't believe that is true either.
If your NAS did the appropriate thing by the EAP/AAA architecture, it
would simply pass through the EAP method negotiation to the client.
And it would be a negotiation between the EAP supplicant/client(peer)
and EAP server(authenticator) where the method selection would get resolved.
The NAS is a transparent man-in-the-middle.

I have no experience with GSS-API, so I cannot directly evaluate how
this differs from "the traditional GSS-API solution",
but I can guess you have an issue, where you want to
present a dynamic list of known EAP methods without prior knowledge.

Even if you could get the active EAP methods, you have another problem,
in that just because an EAP method can be serviced on a given AAA
authenticator,
it doesn't mean it will support your credentials for the given user.
For example, my typical RADIUS server setup will have configured EAP methods:
PEAP w/MS-CHAP and EAP-POTP (RSA tokens), but if use POTP and your account is
not in the RSA authentication server database, you will fail.

Typically, for remote access, it's a matter of knowing what auth
protocol you have to use
to succeed.   The server itself supports a number of user groups,
methods, and credentials for various situations.

Dave.

On 4/1/2010 04:47 PM, Sam Hartman wrote:
> >>>>> "David" = David Mitton <[email-masked]> writes:
>
>     David> Since there isn't an author attribution on this document, I'm
>     David> not sure whom to direct this too....
>
>     David> In section 6.1, Negotiating the EAP Method, the statement is
>     David> made that "the NAS needs to know what EAP method to use."
>     David> This is incorrect.  The NAS does not, in fact it really
>     David> should not, it would break layering.
>
>
>That statement is made in a paragraph explaining why negotiating the EAP
>method to use at the GSS-API layer would be problematic in an EAP/RADIUS
>environment.  In context, in order to negotiate which eap method to use
>at the GSS-API layer, the NAS needs to know which EAP method to use so
>that it can advertize it in the GSS-API OID.  The paragraph then goes on
>to explain some of the reasons why this is impossible to implement with
>the current RADIUS protocol.
>
>The analysis was never contemplating having the NAS inspect EAP
>messages.  The text suggests extending RADIUS to advertize a set of EAP
>type code before EAP starts.  It points out that doesn't actually work,
>although it misses some of the critical reasons it doesn't work.  (It
>does include enough to demonstrate that approach is problematic though).
>
>  You're absolutely right that having a NAS
>inspect the type codes of EAP messages, or restricting the set of EAP
>methods the NAS can work with would defeat the entire point of making
>the NAS EAP-method agnostic.
>
>The conclusion that section then draws is that the traditional GSS-API
>solution to the multi-layer negotiation problem is problematic in an
>EAP/GSS environment.
>
>The specification (draft-howlett-eap-gss) discusses this issue in more
>detail and concludes that multi-layer negotiation is required.

Date: Thu, 1 Apr 2010 20:16:43 +0000
From: David Mitton <[email-masked]>
To: [email-masked]
Subject: Re: Feasibility Analysis, Negotiating an EAP method

<html><HEAD><LINK rel=stylesheet type=text/css href="/webmail/static/deg/css/wysiwyg-3451203449.css" media=all>
<META name=GENERATOR content="MSHTML 8.00.6001.18876"></HEAD>
<BODY>
<DIV>Since there isn't an author attribution on this document, I'm not sure whom to direct this too....</DIV>
<DIV>&nbsp;</DIV>
<DIV>In section 6.1, Negotiating the EAP Method,&nbsp; the statement is made that "the NAS needs to know what EAP method to use."&nbsp;&nbsp; </DIV>
<DIV>This is incorrect.&nbsp; The NAS does not, in fact it really should not, it would break layering.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Think about current RADIUS/EAP authenticators, e.g.&nbsp; Wireless APs, Dial-in servers, or VPN Servers,&nbsp; </DIV>
<DIV>they do not know or care whether PEAP/MS-CHAPV2 or EAP-LAST, or EAP-POTP is going to be used for a session authentication.</DIV>
<DIV>They must know how to encapsulate an EAP message in RADIUS and forward it.</DIV>
<DIV>The RADIUS server decapsulates the frame and directs it to the appropriate EAP authenticator.&nbsp; </DIV>
<DIV>If said EAP mechanism is not installed, or the response is an EAP&nbsp;NAK,&nbsp; the NAS will just receive such an EAP message in </DIV>
<DIV>an Access-Challenge and pass it back to the client.&nbsp; If the client knows another method, it's free to try again, within the current session.</DIV>
<DIV>&nbsp;</DIV>
<DIV>The NAS depends on the RADIUS Server /EAP Authenticator interface to deliver it what it needs to know via RADIUS attributes.</DIV>
<DIV>It should not be inspecting the contents of the EAP messages for type related information.</DIV>
<DIV>Not only does that break layering, but it imposes yet another dependacy on the EAP methods that can be deployed.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If this didn't work, then no new EAP methods would work until all NASes are upgraded.</DIV>
<DIV>Trust me there are enough problems in the deployed implementations already.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Dave.</DIV></BODY></html>

Date: Thu, 1 Apr 2010 16:47:19 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Re: Feasibility Analysis, Negotiating an EAP method

>>>>> "David" = David Mitton <[email-masked]> writes:

David> Since there isn't an author attribution on this document, I'm
David> not sure whom to direct this too....

David> In section 6.1, Negotiating the EAP Method, the statement is
David> made that "the NAS needs to know what EAP method to use."
David> This is incorrect.  The NAS does not, in fact it really
David> should not, it would break layering.

That statement is made in a paragraph explaining why negotiating the EAP
method to use at the GSS-API layer would be problematic in an EAP/RADIUS
environment.  In context, in order to negotiate which eap method to use
at the GSS-API layer, the NAS needs to know which EAP method to use so
that it can advertize it in the GSS-API OID.  The paragraph then goes on
to explain some of the reasons why this is impossible to implement with
the current RADIUS protocol.

The analysis was never contemplating having the NAS inspect EAP
messages.  The text suggests extending RADIUS to advertize a set of EAP
type code before EAP starts.  It points out that doesn't actually work,
although it misses some of the critical reasons it doesn't work.  (It
does include enough to demonstrate that approach is problematic though).

You're absolutely right that having a NAS
inspect the type codes of EAP messages, or restricting the set of EAP
methods the NAS can work with would defeat the entire point of making
the NAS EAP-method agnostic.

The conclusion that section then draws is that the traditional GSS-API
solution to the multi-layer negotiation problem is problematic in an
EAP/GSS environment.

The specification (draft-howlett-eap-gss) discusses this issue in more
detail and concludes that multi-layer negotiation is required.