#23: Section 2.1.1 - Clarifications and typos Changes (by hannes.tschofenig@…):
* cc: hannes.tschofenig@… (added) Comment: Sam responded: Begin forwarded message: From: Sam Hartman <[email protected]> Date: December 19, 2011 7:08:07 PM GMT+02:00 To: "Jim Schaad" <[email protected]> Cc: [email protected] Subject: Re: [abfab] Issue 23 - Clarifications and typos "Jim" == Jim Schaad <[email protected]> writes: Jim> I have to admit this is interesting is that the trust router Jim> would provide the ability for an RP to do this. I had managed Jim> to insert a different entity into the picture and wonder if I Jim> am wrong or of the document is just written odd. Jim> I have an RP code that is written on top of GSS-API. At this Jim> point I need to be able to do a couple of different things. Jim> 1. Is the RP that is my service provider going to talk Jim> directly to the AAA proxy that is hosted with the IdP, or is it Jim> going to go through some local AAA proxy at my side of the Jim> conversation. In our deployment we're assuming that this is a local proxy. Jim> 2. Since as an RP I am doing all of my talking to the AAA side Jim> of the world via GSS-API, I assume that we need to have some Jim> set of items for controlling how the routing is going to be Jim> done in the GSS-API interface. We currently have a way of Jim> getting answers from IdP such as the SAML returned (either in Jim> its entirety or in parts.) And I assume we are going to have Jim> some way of setting the SAML request. However, is the GSS-API Jim> or the RP code itself going to deal with the routing issues? I'm not aware of any proposals for controlling the routing through GSS. I'm not aware of any proposals other than trust router for standardizing controlling the routing. Today that's done through proxy or RP-side config files. Nico responded: Begin forwarded message: From: Nico Williams <[email protected]> Date: December 19, 2011 12:01:08 AM GMT+02:00 To: Jim Schaad <[email protected]> Cc: [email protected] Subject: Re: [abfab] Issue 23 - Clarifications and typos On Sat, Dec 17, 2011 at 9:59 PM, Jim Schaad <[email protected]> wrote: I have an RP code that is written on top of GSS-API. At this point I need to be able to do a couple of different things. 1. Is the RP that is my service provider going to talk directly to the AAA proxy that is hosted with the IdP, or is it going to go through some local AAA proxy at my side of the conversation. A local proxy. 2. Since as an RP I am doing all of my talking to the AAA side of the world via GSS-API, I assume that we need to have some set of items for controlling how the routing is going to be done in the GSS-API interface. Well, the RP application is just calling GSS_Accept_sec_context(). The mechanism invoked by GSS_Accept_sec_context() (GSS-EAP) will do all the work of talking AAA under the covers, invisibly to the application. More likely than not the application only really needs to indicate to the GSS-API that for any particular instance of the application it wants to use one or another configuration/profile. In practice there will often be a single configuration/profile anyways, so that nothing is needed here. If the application really does need direct, fine-grained control how trust routing is done we'd likely end up using a GSS extension such as naming extensions (applied to the acceptor NAME object), credential options (applied to the acceptor's CREDENTIAL HANDLE), or security context options. We currently have a way of getting answers from IdP such as the SAML returned (either in its entirety or in parts.) And I assume we are going to have some way of setting the SAML request. However, is the GSS-API or the RP code itself going to deal with the routing issues? For the sake of simplicity the GSS mechanism should deal with trust routing. The application should limit itself to inspecting the initiator (client) name returned by the GSS-API, or perhaps the application should ask for specific kinds of attributes that it wants to see, or perhaps it should simply select a profile that tells the mechanism the application's requirements. Nico Jim responded: From: "Jim Schaad" <[email protected]> Date: December 18, 2011 5:59:11 AM GMT+02:00 To: <[email protected]> Subject: Re: [abfab] Issue 23 - Clarifications and typos I have to admit this is interesting is that the trust router would provide the ability for an RP to do this. I had managed to insert a different entity into the picture and wonder if I am wrong or of the document is just written odd. I have an RP code that is written on top of GSS-API. At this point I need to be able to do a couple of different things. 1. Is the RP that is my service provider going to talk directly to the AAA proxy that is hosted with the IdP, or is it going to go through some local AAA proxy at my side of the conversation. 2. Since as an RP I am doing all of my talking to the AAA side of the world via GSS-API, I assume that we need to have some set of items for controlling how the routing is going to be done in the GSS-API interface. We currently have a way of getting answers from IdP such as the SAML returned (either in its entirety or in parts.) And I assume we are going to have some way of setting the SAML request. However, is the GSS-API or the RP code itself going to deal with the routing issues? Jim ---- Hannes posted to the list: Hi Jim, In issue #23 http://trac.tools.ietf.org/wg/abfab/trac/ticket/23 you write: “ 1. The rules determinaion in pagraph #2 might want to refer to levels of assurence which is one of th4e ways in figuring out some of these issues. Note that this may need to change how the realm of the NAI is going to be determined if you are looking ath the routing issues in paragraph #1 2. Paragraph #3 is ambigious in at least one respect. I am not clear if the question is one of the RP relying on the IdP in roder to get a decision, or if the text is saying if the IdP is going to agree to talk to the RP. This should be clarified. I believe that both sides of this question need to be covered - but in separate locations. “ The current version of the document uses the term “Rules determination” as a way to indicate that the RP has to make a decision of where to route the AAA mechanism. This term is confusing. I agree with you that the writeup is a bit short with regard to what are the decision criteria. In fact, there is a separate document (which is not yet a working group item) that discusses these aspects in much more detail, see http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02 I suggest to reference that document. I agree that the LoA may have an impact on the routing, particularly when it comes to the broader question of assessing the operational security of some of the providers. Here is paragraph #3: Rules determination covers a broad range of decisions about the exchange. One of these is whether the given RP is permitted to talk to the IDP using a given federation at all, so rules determination encompasses the basic authorization decision. Other factors are included, such as what policies govern release of information about the principal to the RP and what policies govern the RP's use of this information. While rules determination is ultimately a business function, it has significant impact on the technical exchanges. The protocols need to communicate the result of authorization. When multiple sets of rules are possible, the protocol must disambiguate which set of rules are in play. Some rules have technical enforcement mechanisms; for example in some federations intermediates validate information that is being communicated within the federation. I agree with you that the writeup is confusing. I believe it needs to take some of the work we did afterwards, such as with the document I mentioned above, into consideration. Ciao Hannes -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: Keywords: | --------------------+-------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/abfab/trac/ticket/23#comment:1> abfab <http://tools.ietf.org/abfab/> _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
