>>>>> "Jim" == Jim Schaad <[email protected]> writes:
James> Also does it make a difference in how the channel to the
James> service is created? I.e. it makes much more sense to use
James> host-based server names if one is using TLS as the channel
James> between the application and the channel, but how the RP
James> decides which IdP or federation to use is not going to be
James> based on host-based service names. I guess part of my
James> question is going to be is naming different for the RP (from
James> the point of view of the client) as oppose to the naming of
James> other entities in the system.
>>
>> This section is discussing support for host-based names of GSS
>> acceptors.
Jim> At
>> least as described currently an IDP is not a GSS acceptor. In
>> the KMP presentation we gave in Prague, we proposed creating a
>> GSS acceptor service associated with an IDP, but that is not
>> discussed at all in this document.
Jim> I was more worried about the problems that the client had doing
Jim> the comparison between what the RP gave to the IdP and what the
Jim> RP gave to the client as a proper name rather than what the GSS
Jim> acceptor was using.
It's actually the IDP that does this.
The client gives its idea of GSS acceptor name to the IDP; the RP gives
its idea of the GSS acceptor name to the IDP.
In a typical deployment, I'm expecting that some AAA proxy close to the
acceptor would verify that the acceptor is authorized to claim whatever
host name it actually claims. I'm imagining that the border proxy
between the IDP's realm and the acceptor's realm (in a RADSEC style
deployment where these entities speak directly) would confirm that the
RP is from the realm it claims and that realm is permitted to claim the
hostname that the acceptor claimed.
This leaves the IDP it self doing a binary comparison of the channel
binding attributes the client/subject sent to the ones from the RP.
Any attribute sent by the client must be present in the RP set and must
compare identically.
This all needs to be spelled out: the proxy behavior sections need to be
written. I think the IDP behavior is spelled out in the mechanism
document.
>>
James> 21 - Section 3.4 - I need to have an idea of what entities
James> are going to be using the GSS-API per-message security
James> services. There is a difference in how I think about this if
James> this is done between the subject and the RP as oppose to
James> between the RP and the IdP or the subject and the IdP. I
James> also need to come to grips with how many different MSKs are
James> going to be generated in this system. I don't have a good
James> idea of this from this section.
>>
>> GSS initiator and acceptor use the per-message services. I.E. the
>> IDP and
Jim> RP.
>> Only one MSK in the entire system.
>>
Is there a GSS key between the client and the RP before the EAP has
Jim> finished? At what point do messages between the client and the
Jim> RP become protected w/o the use of a channel which is
Jim> independently providing protection.
There is not a key before EAP generates one; typically the RP doesn't
learn this key until eap succeeds.
Unless we choose to introduce a DH exchange or the like, then things
between the initiator and RP are not protected until eap succeeds.
Currently the only things sent there are:
* the EAP conversation
* Initiator's request for RP name or initiator's indication of what RP
name it is using
* The mutual authentication flag that we need to MIC
All of these things would go in the clear in something like TLS.
In terms of channel attributes.
There are a couple of basic approaches you could use.
The GS2 approach is that you never use per-message services, you use a
protected channel if you care about security and you perform channel
binding.
Contrast this with say the approach used by the Kerberos administration
service. There the channel is never protected, but gss_wrap is used to
protect every message.
In this model really you need very little from the channel.
I think explicitly describing these two models might help; what do you
think?
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
