Subject: Re: [abfab] #23: Section 2.1.1 - Clarifications and typos

From: "abfab issue tracker" <[email-masked]>
Date: Sat, 10 Mar 2012 13:28:35 -0000

#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-masked]>
 Date: December 19, 2011 7:08:07 PM GMT+02:00
 To: "Jim Schaad" <[email-masked]>
 Cc: [email-masked]
 Subject: Re: [abfab] Issue 23 - Clarifications and typos

 "Jim" == Jim Schaad <[email-masked]> 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-masked]>
 Date: December 19, 2011 12:01:08 AM GMT+02:00
 To: Jim Schaad <[email-masked]>
 Cc: [email-masked]
 Subject: Re: [abfab] Issue 23 - Clarifications and typos

 On Sat, Dec 17, 2011 at 9:59 PM, Jim Schaad <[email-masked]>
 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-masked]>
 Date: December 18, 2011 5:59:11 AM GMT+02:00
 To: <[email-masked]>
 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/>