Subject: [abfab] Issue 23 - Clarifications and typos

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sat, 17 Dec 2011 19:02:00 +0200

Hi Jim, 

In issue #23 http://trac.tools.ietf.org/wg/abfab/trac/ticket/23 you
write:
"
1.	The rules determinaion in pagraph #2
<http://trac.tools.ietf.org/wg/abfab/trac/ticket/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 <http://trac.tools.ietf.org/wg/abfab/trac/ticket/1>  
2.	Paragraph #3 <http://trac.tools.ietf.org/wg/abfab/trac/ticket/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

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 17 Dec 2011 19:59:11 -0800

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Saturday, December 17, 2011 9:02 AM
To: [email-masked]
Subject: [abfab] Issue 23 - Clarifications and typos

Hi Jim, 

In issue #23  <http://trac.tools.ietf.org/wg/abfab/trac/ticket/23>
http://trac.tools.ietf.org/wg/abfab/trac/ticket/23 you write:

"

1.      The rules determinaion in pagraph
<http://trac.tools.ietf.org/wg/abfab/trac/ticket/2> #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  <http://trac.tools.ietf.org/wg/abfab/trac/ticket/1> #1 

2.      Paragraph  <http://trac.tools.ietf.org/wg/abfab/trac/ticket/3> #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>
http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02

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:

   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

---

From: Nico Williams <[email-masked]>
Date: Sun, 18 Dec 2011 16:01:08 -0600

> local AAA proxy at my side of the conversation.

A local proxy.

> 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.

> 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
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Dec 2011 12:08:07 -0500

>>>>> "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.