> -----Original Message----- > From: Sam Hartman [mailto:[email protected]] > Sent: Tuesday, April 26, 2011 2:10 AM > To: James Schaad > Cc: [email protected]; 'Eliot Lear' > Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 > > >>>>> "James" == James Schaad <[email protected]> writes: > > > James> 1. Introduction para 3 - I want to make sure that your > James> definition of federation is one that you want to make. > James> Specifically it would appear that there can be federations > James> even within a single entity in the event that actor providing > James> the identity information is not the same as the RP. Would > James> you consider a single Kerberos or Windows enterprise to be a > James> federation. In these cases the IdP being the login service > James> and the RP being somebody granting access to a resource (in > James> windows possibly by an RPC). I generally think of federation > James> as being between two different entities rather than within a > James> single entity but using multiple servers. > > I tend to agree with you that a lot of problems show up in the cross- > organization case. I think it's important to make it clear we're signing up to > that and a solution working within a single organization is not sufficient. I also > think it would be honest to indicate we're optimizing for the cross > organization case. I don't think we should forbid our technology being used > within a single organization nor ignore concerns that happen when that is > done. What are your thoughts? >
I don't have a problem with a focus on cross-organization cases, I think that is where this document should be focused. I was actually trying to drive at the question of the definition of what a 'federation' was and trying to determine if the one given was both a good one and a viable one. That is a federation is a relationship that defines 'technical signaling, trust and a common understanding of semantics between the RP and IdP'. Nothing in this definition rules out federation within an organization. In that case the second two element should be easy leaving only the first as a problem. The question was more one of is the definition as given potentially so broad as to eliminate, for some people, the concept that a single organization has the elements of a federation within it. The comment was more intended to make you think that to say what is there is wrong. > > James> 3. Section 1.1 - I am still AAA challenged. Is it more > James> correct to say 'a radius or diameter server'? Do you want to > James> put in a generalized statement that says you use radius but > James> it also applies to diameter? > > We're using RADIUS for the example here. Project Moonshot is only > focusing on RADIUS, but ABFAB needs to be/people are working on making it > technology neutral. > We should clarify in the doc if is this not clear. > (And obviously there is no need to mention Moonshot's implementation > choices at all in the doc.) No - you have defined the components of an IdP and did not include Diameter as an option. I think that it needs to be included as part of what an IdP consists of. I think that it would be perfectly acceptable to put a paragraph in here that says "In all places where Radius is used, Diameter could also be used unless otherwise stated." > James> 10. Possible issue to include here. In the presence of > James> multiple federations, the naming of individuals can become > James> murky especially if one is trying to associate a single > James> individual from different federations. Asking a question > James> such as does John Doe belong to an IdP (in the absence of > James> authentication) may get an answer for the wrong John Doe. > > Yes. > This is worth mentioning in my opinion. > > James> 11. Section 1.4 - Overview a) I think you might need to have > James> a step 2a - Client Application creates a channel to the RP. > James> This is not done by the GSS-EAP mechanism as I had originally > James> assumed. Let's make it clear additionally that fact will be > James> needed in order to setup the channel binding at a later time. > > James> b) in step 5 either /forward a RADIUS request/ or /forward > James> RADIUS requests/. AAA ignorance - would message be better > James> than request to avoid confusion between RADISU request and > James> GSS/EAP request? - > > I think RADIUS message would be OK. The particular type of message is called > a request, but we don't need to say that. Please change just to eliminate the redundancy. After re-reading this paragraph I think that the term forward should be replaced with send. The RP 'sends' rather than 'forwards' the RADIUS message as it conceptually creates the RADIUS request for the IdP. > > James> I would ignore how the SAML request is > James> encoded at this point. So maybe s/SAML request as a series > James> of attributes/ SAML request for a set of attributes/ s/.././ > > I'd personally just leave it as SAML request. > After talking to Rhys and Josh about what you can and cannot do with various > types of SAML requests it is better not to get into details here. I agree - better is s/SAML request as a series of attributes/SAML request/ > > James> c) request that you go back and use subject rather than > James> principal in this section. The change in terminology is not > James> introduced. > > OK. > > James> d) in step 9, I think I have a problem with the last > James> sentence. These policy checks would have been done by the > James> AAA system or the RP and not by the IdP. As such I don't > James> think the title for the paragraph makes sense. > No, I think the IDP makes these checks as well. I am not saying that the IdP does not make the policy checks. I am referring to the "Additional policy checks" in the last sentence. Including this here rather than in the discovery process makes the paragraph title problematic. However I do not need a change here. > > Consider the PLASMA example. > An IDP may well know exactly who its organization permits to be a PLASMA > policy point and may forbid others from providing that service. > Some IDPs will have very open policy here; some will not. > > I agree that the AAA and RP may also apply policy. > > > James> e) Step 10, Do we need to be explicit that the MSK return > James> must be encrypted somehow? Based on the conversations last > James> week there appears to be a problem in that while RADIUS has > James> the ability to return encrypted responses, it is not native > James> to Diameter. Also does this need to be a new attribute or > James> does the attribute already exist (in both systems). > > AAA keywrap is probably not something we want to go into here. > There are a lot of AAA deployments where the attribute is not encrypted at > all. > I think in our mechanism document we want to make support for encryption > mandatory in the GSS acceptor. I think our BCPs we definitely want to make > support for implementing this attribute mandatory. > I don't think we want to go into that detail here, although if someone > provided text discussing the issue for elsewhere in the document that would > be good. I can live with this not being covered. It may want to go into something marked security considerations just to make sure it is not lost. How the encryption is done is going to be highly variable, in that I agree. > > James> Is the > James> sentence at the end of the paragraph wrong? Is it returned > James> to the subject (not covered by the title) or the RP? The > James> subject should already have the MSK > > Here it is returned to the RP; the subject definitely already has it. > > James> f) I don't understand part of step 11 -- It may have > James> information that leads it to make additional attribute > James> queries. I can see it needing to make additional attributes > James> because it needs more information, but not because it has the > James> information it needs. > I agree with your confusion but don't know what was intended here. > > James> 13. Section 2 - What is this "end host" that is referred to > James> in the second paragraph? Is this the IdP, the subject or > James> some new entity. - Getting all of these names straight > James> without having a glossary is going to kill me eventually.'' > > The subject. > I think end-host probably wants to get collapsed into subject. Sounds good. As stated the fact that there are multiple names but not a table of those names in the different protocols is confusing. Actually adding that table would probably be both an interesting exercise as well as making a good single point of reference. > > James> s/connumication/communication/ > > James> 14. Section 2.1.1 - discovery --- I don't know that I don't > James> have a slight problem with the first sentence in this > James> section. If you are going to tell me that I need to properly > James> identify the end points of the communication, > James> then I want to > James> see more details on what is considered to be proper here. > James> For one thing, I assume that this identification is only true > James> as far as the AAA substrate is concerned. This means that > James> asking for a service at a realm would be considered to be > James> sufficient as oppose to having to know who is providing the > James> service. (i.e. I want some [email protected] as oppose to a > James> specific one. It might be that additional restrictions are > James> required for a type of idp, but that is not covered here.). > > The following sentences attempt to clarify. > The realm portion of a NAI identifies a conceptual endpoint for sending a > request in AAA. > Identifying the endpoint making the request is more complex; how that is > handled kind of depends on the specific technical trust mechanism in play. > Yes I think that flows better. > > James> How much of the rules determination is to be done by the RP > James> and how much by the AAA substrate? > > This is probably an implementation detail. > An RP that has multiple places it can start in the AAA substrate needs to pick > one. > However conceptually you can think of that combination as an RP plus AAA > proxy (possibly all within one process) so I think this is an implementation > matter. I agree that it does not need to be covered in this case. > > James> Looking at para 3 - I am wondering if sentence two should be > James> stated as "One of these is whether the given RP is permitted > James> to rely on the IDP using a given federation at all,...". The > James> question is one of does the RP trust the IdP as oppose to > James> does the IdP allow the RP to talk to it. The rules > James> determination is going to be done differently for the two > James> sides. > > I think either party can decide not to talk to the other party. > The use case motivating that sentence was explicitly a case where an IDP was > selective in what RPs it permitted and where a federation did not allow all > RPs to talk to all IDPs, not the case where the RP had a trust decision to > make. > Obviously, though, both parties may need to decide something. >From the text in place, I think that it states just the opposite. I.e. can an RP rely on the IdP. I would assume that the IdP would actually do its own rules determination rather than rely on anything supplied by the RP except as one input to the IdP rules determination process. A such the rules used by the IdP are covered elsewhere? > > James> For the AAA Proxy - the last sentence needs to be motivated. > James> I can see flooding routing information but the reason for > James> doing name constraints escapes me at the moment. > > Routing information in an AAA fabric is effectively name constraints in both > directions. "This way for FOO.COM!" "Messages coming from that direction > can claim RPs in realms A, B, C and D!" How about s/flood naming constraints to/flood naming constraints on routed traffic to/ I think this would make it more clear what you are talking about. > > > James> 15. Section 2.3 - Application to Service -- This section > James> discusses the use of GSS-API, however I believe that it also > James> needs to include a discussion of the channel that is to be > James> used between the application and the server as this is not an > James> implicit part of the GSS-API system. This channel may have > James> some specific requirements that need to be discussed as well. > > I'd really need to see text here, because I don't know what we'd want to say > about the channel. Well I guess the first question is if any channel that is used needs to support channel binding? Also I think that it might be necessary to state that if protocols want a more definitive statement on who the RP is, then this needs to be provided by the channel (actually I am not sure that is the case). There are questions about privacy on the information setup prior to the GSS-EAP mechanism being setup as well as authentication. These may be requirements of the channel. I am not sure at this point what all is needed here. > > James> 16. Section 2.4 - I don't understand the title of this > James> section. What does this have to do with personalization? > James> Perhaps Attribute or similar word would be better than > James> personalization. A look forward in this section to the one > James> on privacy might be indicated as this would be a good > James> location to talk about the issues of what information should > James> be released from the IdP to the RP and how much it should be > James> under the control of the federation agreement and how much > James> under the control the subject. > > I would be fine with both of these changes. > > James> 17. Section 2.5 - what happened to the text in this section? > > I don't know. Did it ever have text? I have no idea. For all I know that section exists just to hold the picture which is odd. If it needs text then it needs to be supplied. > > > James> 19 - section 3.1 - I would suggest a new title as it would be > James> good to suggest who is being mutually authenticated -- yet > James> another name for somebody - who are the initiator and the > James> acceptor > > Section 3 is all about GSS-API, which only has two endpoints, so I don't see > any other options than these two endpoints. > > initiator is the GSS name for subject; acceptor is the GSS name for RP. Ok - either the table of names or a sentence saying 'Mutual authentication occurs between the subject and the RP." Would both address my problem. > > James> Please expand on the difference between bullets 1 and 2 in > James> this section. It appears to me that the first sentence in > James> both sections are saying the same thing - that the initiator > James> trusts that the name it has given for the target > James> name/acceptor correctly names and describes the acceptor. If > James> there is a difference in these concepts I for one don't > James> understand it from the text. > > The second bullet covers the case where the initiator does not supply a > target name. > I'd be happy to add a sentence to the second bullet that the second bullet is > a subset of the first when a target name is provided or otherwise clarify. Sounds good > > James> 20 - section 3.3 - In the next to last paragraph, would host > James> names work better in the case that secure SRV records w/ > James> DNSSEC are used? > > If you were willing to trust DNS both on the initiator and the RP and do some > work on how applications handle these names, you could improve the > situation. > To me, it seems a big assumption to assume that your application > authentication trust and your DNS trust are aligned, especially when you'd > need to make that assumptions on both sides of a federation. > It's true sometimes and possibly enough of the time to support, but not > enough of the time to rely on. It might make sense to change s/other insecure referrals/other referrals/ since in these cases the referrals would be assumed not to be AAA referrals. > > James> I also do not understand how to resolve the > James> decision in paragraph two to say we need to use realm names, > James> but the last paragraph says that we need to support > James> host-based service names. How am I supposed to reconcile > James> these differences. > > Putting hosts into a realms is a mechanism for more easily supporting host > names. > There is more detail on this in the actual mechanism document. > Ok - will read that document again. > James> Also does it make a difference in how the > James> channel to the service is created? I.e. it makes much more > James> sense to use host-based server names if one is using TLS as > James> the channel between the application and the channel, but how > James> the RP decides which IdP or federation to use is not going to > James> be 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. 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. I was more worried about the problems that the client had doing the comparison between what the RP gave to the IdP and what the RP gave to the client as a proper name rather than what the GSS acceptor was using. > > 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 RP. > Only one MSK in the entire system. > Is there a GSS key between the client and the RP before the EAP has finished? At what point do messages between the client and the RP become protected w/o the use of a channel which is independently providing protection. Jim > > > James> _______________________________________________ > abfab mailing > James> list [email protected] > James> https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
