> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Sam Hartman > Sent: Wednesday, January 19, 2011 5:34 PM > To: Jim Schaad > Cc: [email protected] > Subject: Re: [abfab] Comments on draft-lear-abfab-arch-01 > > >>>>> "Jim" == Jim Schaad <[email protected]> writes: > > Jim> In step 2 A couple of questions come to mind here - which > Jim> authentication mechanism are selecting? The End Host to IdP or > Jim> the End Host to the Relying Part? Are there any options here > Jim> or is there only a single possibility? > > There is no authentication of the end-host to the RP. > The end-host authenticates to the IDP. > There is a key confirmation step where the end-host and RP prove they have > the same session key. > In some sense, that performs an authentication function; it definitely binds > the RP->IDP authentication with the end-host->IDP authentication.
I was expecting to see some degree of authentication of the RP to the end-host before the process started. If this is not the case then all of the name matching logic is going to occur in the IDP and none of it in the end-host which has the best guess as to who it thinks it should be talking to. Are you referring to a step where the end-host and RP prove they have the same session key to each other, or are they trying to prove this to a third party? I can figure out that the first occurs but not the second. Currently the only check that is performed is that the name is the same. If we are clobbering the name with the key, then it is vital that the end-host and the RP agree on the name form of the RP before they are clobbered and given to the IDP. You did not address the question of a single possibility - the current text says it is a selection step, but if the selection is done by the specification then this is not really a selection that is part of the exchange. > > Jim> In Step 3 For various reasons, I think one will want to > Jim> establish a secure link to from the Client Application to the > Jim> RP either before - or as - it is supplying the NAI to the RP. > Jim> It might however been that you are really only saying that you > Jim> are sending the realm portion of the NAI to the RP. That would > Jim> be a different story, but you may still want to get some type > Jim> of secure link. > > You're typically only sending the realm portion if your EAP method uses > privacy identifiers (the good ones do). > > A secure link to the RP at this stage is out of scope for a GSS substrate for > abfab in my opinion. > It adds a lot of mess, and there are better ways of doing most of what you > are probably trying to do. > > Also, note that since the end-host has no credential for the RP, and this is a > huge feature of the architecture, your options are limited. So we are not even planning to say that we are going to be using TLS here. However it would still be possible to do some type of leap-of-faith credential here where we can get a secure link - which I think you are really planning to do since you talked about comparing the keys using the IDP as an arbiter. > > Jim> Section 3.1 - in Paragraph 3 - It specifies that we are going > Jim> to put the NAI in the GSS_C_NT_USER_NAME field of GSS-API, is > Jim> it going to be the responsibility of the GSS-API layer to > Jim> fragment the realm portion of name from the full NAI depending > Jim> on if it is talking to the RP or the IdP? > > Um. > I think you're a bit confused about what role GSS-API fills here. > The NAI is an input to the GSS-API, which locally on the end-host feeds it to a > specific EAP method. > That method will hide it if that method hides identity. Ok - then I am confused. Are we talking about having a single GSS-API method which is going to coordinate both of the secure links we are looking at, or are there going to be two different GSS-API methods, or is the end-host to RP link not going to be covered by GSS-API? My assumption was the first - that is a single GSS-API method was going to have to do the secure link from the end-host to the RP as well as the EAP conversation to the IDP. In this case the question does make sense as the name being sent over EAP is different than that being sent to the RP, but both are coming out a single common GSS-API method > > Jim> There is no mention in this section that there may be multiple > Jim> IdPs for a single realm that could be used by the RP and the > Jim> selection of which IdP it wants to use is going to be based on > Jim> the set of attributes that the RP needs or a level of > Jim> authentication that is required by the RP (see [sp800-63-1] > Jim> NIST SP 800-63-1 "Electronic Authentication Guideline", > Jim> December 2008 as examples). > > True, basically because there's no existing protocol mechanism to accomplish > the end-host finding out what the RP wants. > This is kind of a GSS failing; there is some Microsoft work that could expand > GSS in some ways. > Abfab can take advantage of this whenever GSS gains the feature. > > I think I have an action item to discuss federation and IDP selection (although > someone else may have the action item for IDP selection--can't remember). > However it's more going to be about future extensions and directions for > expansion. It's a hard problem - as long as that is discussed we can probably punt for now. > > > Jim> Section 3.2 Has the sentences " Aside from a valuable secret > Jim> being exposed, a synchronization problem can also often > Jim> develop. Since there is no single authentication mechanism > Jim> that will be used everywhere there is another associated > Jim> requirement:" I have a couple of issues here. First there is a > Jim> problem which is stated - i.e. synchronization - but the next > Jim> sentence does not appear to expand on the problem but rather > Jim> deals with a different issue. I would like to have the first > Jim> thought finished before going onto the second one. I think > Jim> this paragraph is supposed to be talking about issues that we > Jim> have been taught - but the word Since does not convey this is a > Jim> separate issue we have dealing with. > > Help with wording would be greatly appreciated here. Not a problem - Elliot - what did you mean by a synchronization problem? > > Jim> In the sentence "through the authenticator (i.e., service > Jim> provider)" - s/service provider/relying party/ > > Jim> Section 3.5 In this picture - I believe that it would be more > Jim> accurate to have the EAP stream go directly through the > Jim> Federation layer - this would not be routed as it is E2E. > > No, I think the EAP stream is routed. > > Just as TLS is routed over IP. > While TLS is routed over IP - I generally think of it as being channel and thus direct between the two parties. I ignore the routing that is being done by the IP layer as it does not affect the data being transported. This is not the same as with the RADIUS/DIAMETER stream where the routing layer can change the contents of the message as it travels through the federation layer. Thus I think that representing the data flows differently in the picture makes sense. > > Jim> Section 4.3 Given that you have stated that we are going to use > Jim> the Kerberos realm naming, on which I have no opinion, I think > Jim> that there should be some text about how the end host is going > Jim> to make a decision that it is talking to the correct RP to > Jim> begin with. It does not have any pre-existing security > Jim> relationship with the realm of the RP. > > It kind of needs to trust the RP for some of this. > It needs to derive a name for the RP from input it gets from the user or a > trusted referral. > Then, the IDP and some proxy goo is responsible for making sure that the RP > it is talking to is the RP it names. But there is a difference between relying on just the IDP to do the name matching, and the end-host doing the name matching and then sending the name that it gets from the RP to send to the IDP for the final name matching check. I am worried about the question of trying to go from a DNS name to a NAI name at this point. > > Jim> Additional Issues: > > Jim> 1. The document is currently written in terms of dealing with > Jim> an Identity provider, and I can understand why that is so as > Jim> without an identity not much will happen. However it seems to > Jim> me that there is also a desire to be able to talk to an > Jim> attribute service in much the same way. However it is not > Jim> clear that there is a need for the End Host to talk to the > Jim> attribute provider - that communication should be thought of as > Jim> passing between the IdP, the RP and the AtP. The IdP may need > Jim> to get a different or better identity proof as part of that > Jim> conversation. > > Hmm. > > Jim> 2. I am not sure if there needs to be a discussion on what > Jim> needs to be a part of a federation agreement. One of the > Jim> issues that I can see as being troublesome as it does not seem > Jim> to be vastly expandable is the question of what makes for an > Jim> equivalent statement. Is it to be expected that the SASL > Jim> statements are going to be made in terms of the federation > Jim> agreement attributes, or does there need to be available to the > Jim> RP some type of mapping statement? > > I hope we can avoid discussions of what goes in a federation agreement. I can understand this, however I think that there needs to be some high level discussion of questions like how mapping of statements should be done. Jim > > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
