> -----Original Message----- > From: Sam Hartman [mailto:[email protected]] > Sent: Wednesday, April 27, 2011 4:16 AM > To: Jim Schaad > Cc: [email protected]; 'Eliot Lear' > Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 > > >>>>> "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. >
Ok - so we have here an even more important case to say that the channel between the client and the RP needs to have channel binding. Since we don't have the channel binding data for the IdP to compare unless the channel is going to produce it. There is no channel binding data from the GSS-EAP mechanism until the MSK is created. This would not be an issue if we were comparing text names, but then we have the issue of the difference between the DNS name used by the client and the AAAA realm name used by the RP. However this is leaving me confused about what the acceptor name form and value(s)(?) are supposed to be. I need to go back and review again what the form of the name you had on the screen was so that I can look for the different fields. > >> > 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. Ok - this is what I thought. Any other keys would come from the channel being used. > > 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 the clear in or in the clear or ?? > > 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? Yes I think that this would be useful as two extremes. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
