Let's see how far I can demonstrate my lack of understanding. It seems to me to be a good way to figure out if there are problems with the document. The mailing list may have addressed some of these issues, I am just now catching up on it.
Jim In section 1.1 Current: Some deployments may be required to deploy message routing intermediaries Suggested: Some instantiations may be required to deploy message routing intermediaries The expansion of NAI needs to be moved forward in the document. In step 2 A couple of questions come to mind here - which authentication mechanism are selecting? The End Host to IdP or the End Host to the Relying Part? Are there any options here or is there only a single possibility? In Step 3 For various reasons, I think one will want to establish a secure link to from the Client Application to the RP either before - or as - it is supplying the NAI to the RP. It might however been that you are really only saying that you are sending the realm portion of the NAI to the RP. That would be a different story, but you may still want to get some type of secure link. Note to self - in step 5 what is the security on the RP claim of identity In Step 7 You say that it happens between the endpoints - but the endpoints are not defined in this case. I believe you actually mean the IdP and the Principal but there are other endpoints it could be. In Step 8 I have a complete lack of understanding of the last sentence of this section. I don't have any idea of how this statement follows from the preceding. I can see it as saying that the IdP will know that the Principal and it are authenticated to the same RP. Section 3.1 - in Paragraph 3 - It specifies that we are going to put the NAI in the GSS_C_NT_USER_NAME field of GSS-API, is it going to be the responsibility of the GSS-API layer to fragment the realm portion of name from the full NAI depending on if it is talking to the RP or the IdP? There is no mention in this section that there may be multiple IdPs for a single realm that could be used by the RP and the selection of which IdP it wants to use is going to be based on the set of attributes that the RP needs or a level of authentication that is required by the RP (see [sp800-63-1] NIST SP 800-63-1 "Electronic Authentication Guideline", December 2008 as examples). Section 3.2 Has the sentences " Aside from a valuable secret being exposed, a synchronization problem can also often develop. Since there is no single authentication mechanism that will be used everywhere there is another associated requirement:" I have a couple of issues here. First there is a problem which is stated - i.e. synchronization - but the next sentence does not appear to expand on the problem but rather deals with a different issue. I would like to have the first thought finished before going onto the second one. I think this paragraph is supposed to be talking about issues that we have been taught - but the word Since does not convey this is a separate issue we have dealing with. In the sentence "through the authenticator (i.e., service provider)" - s/service provider/relying party/ Section 3.5 In this picture - I believe that it would be more accurate to have the EAP stream go directly through the Federation layer - this would not be routed as it is E2E. Also it might make sense to have it wrap through the Server Side box. Section 4.3 Given that you have stated that we are going to use the Kerberos realm naming, on which I have no opinion, I think that there should be some text about how the end host is going to make a decision that it is talking to the correct RP to begin with. It does not have any pre-existing security relationship with the realm of the RP. Additional Issues: 1. The document is currently written in terms of dealing with an Identity provider, and I can understand why that is so as without an identity not much will happen. However it seems to me that there is also a desire to be able to talk to an attribute service in much the same way. However it is not clear that there is a need for the End Host to talk to the attribute provider - that communication should be thought of as passing between the IdP, the RP and the AtP. The IdP may need to get a different or better identity proof as part of that conversation. 2. I am not sure if there needs to be a discussion on what needs to be a part of a federation agreement. One of the issues that I can see as being troublesome as it does not seem to be vastly expandable is the question of what makes for an equivalent statement. Is it to be expected that the SASL statements are going to be made in terms of the federation agreement attributes, or does there need to be available to the RP some type of mapping statement? _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
