Subject: [abfab] Levels of Assurence

From: "Jim Schaad" <[email-masked]>
Date: Thu, 8 Dec 2011 21:00:55 -0800

As part of the plasma work, one of the things that has been stated as a
requirement is that the RP can insist on a level of assurance for the client
to be authenticated with.  At this point in process, I don't care about the
specifics of how the LOA is actually specified, but I am interested in how
the data specifying this would be conveyed.

At this point I can see two different methods to convey the information:

1.  The data is carried in a RADIUS attribute.  Such an attribute may
already exist, I have not done any type of exhaustive search, and just needs
to be documented.  I can see other access points wanting to require an LOA
in just the straight RADIUS AAA world.

2.  The data could be carried in a SAML request.   As long as the IdP and
the AAA Radius server are co-existent this would not be a problem.  But it
does mean that the SAML request now needs to be parsed for some information
before the EAP processes are run in order to determine which EAP methods are
acceptable to the RP.

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 8 Dec 2011 23:27:36 -0800

While reading my back log of messages, I discovered the following text:

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

Is this a real thing and is this something that needs to be handled by
having separate AAA proxy and IdP servers.  If so does this mean that we
need to look at that interface more closely?

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jim Schaad
> Sent: Thursday, December 08, 2011 9:01 PM
> To: [email-masked]
> Subject: [abfab] Levels of Assurence
> 
> requirement is that the RP can insist on a level of assurance for the
client to
> be authenticated with.  At this point in process, I don't care about the
the
> data specifying this would be conveyed.
> 
already
> exist, I have not done any type of exhaustive search, and just needs to be
> documented.  I can see other access points wanting to require an LOA in
just
> the straight RADIUS AAA world.
> 
> does mean that the SAML request now needs to be parsed for some
> information before the EAP processes are run in order to determine which
> EAP methods are acceptable to the RP.
> 
> Jim
> 
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 9 Dec 2011 10:13:59 +0200

Hi Jim, 

Here is the challenge with the level of assurance concept: they are not
just a matter of how the user was authenticated but the different levels
are reflected in the overall system design. 

As such, it is not sufficient to just communicate from the IdP to the RP
that a specific transaction is, for example, LoA 4. The RP should "know"
that since the entire system has to be designed in such a way and the
IdP and the RP are likely to have an agreement (out of band) to ensure
the RP that the IdP does actually what it is claiming to do.  (You may
call this "trust relationship".) 

Having said that NIST SP 800-63 (as it is available today; revision
pending) has a serious shortcoming. It focuses with the LoA concept
heavily on identity proofing and authentication but does not consider
the attribute assurance and privacy concepts that are associated with
the release of data. In a complete system, like we are working on in
ABFAB, this is very relevant. 

So, while I like NIST SP 800-63 a lot I am eagerly waiting for an update
of their document (which should have been out there already) to see
whether we can reference something more complete for the purpose of our
discussion. As far as the conveyance of the LoA in RADIUS / Diameter /
SAML / etc. concerns I am less convinced about the value. 

Just yesterday I suggested to the OAuth working group that the different
levels of assurance could serve as a good way to describe security
properties of a system. See my mail here:
http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html

Ciao
Hannes

> Of ext Jim Schaad
> Sent: Friday, December 09, 2011 9:28 AM
> To: [email-masked]
> Subject: Re: [abfab] Levels of Assurence
> 
> There is no mention in this section that there may be multiple IdPs
for
> a
> or a level of authentication that is required by the RP (see
[sp800-
> 63-1]
> > As part of the plasma work, one of the things that has been stated
as
> a
> > 2.  The data could be carried in a SAML request.   As long as the
IdP
> and

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 9 Dec 2011 00:19:08 -0800

> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:[email-masked]]
> Sent: Friday, December 09, 2011 12:14 AM
> To: ext Jim Schaad; [email-masked]
> Subject: RE: [abfab] Levels of Assurence
> 
> Hi Jim,
> 
just a
> matter of how the user was authenticated but the different levels are
> reflected in the overall system design.
> 
that a
> specific transaction is, for example, LoA 4. The RP should "know"
> that since the entire system has to be designed in such a way and the IdP
and
> the RP are likely to have an agreement (out of band) to ensure the RP that
> the IdP does actually what it is claiming to do.  (You may call this
"trust
> relationship".)

I think that this may be required in both directions.  That is the RP may
need to tell the IdP what it wants as well.

I completely agree that there is going to need to be an OOB agreement about
what the values mean.  But I still potentially want to do the selection
process.

> pending) has a serious shortcoming. It focuses with the LoA concept
heavily
> on identity proofing and authentication but does not consider the
attribute
> assurance and privacy concepts that are associated with the release of
data.
> In a complete system, like we are working on in ABFAB, this is very
relevant.
> So, while I like NIST SP 800-63 a lot I am eagerly waiting for an update
of their
> document (which should have been out there already) to see whether we
> can reference something more complete for the purpose of our discussion.
> As far as the conveyance of the LoA in RADIUS / Diameter / SAML / etc.
> concerns I am less convinced about the value.
> 
properties
> of a system. See my mail here:
> > 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).
> >
> > having separate AAA proxy and IdP servers.  If so does this mean that
> > we need to look at that interface more closely?
> >
> > Jim
> >
> >

---

From: Josh Howlett <[email-masked]>
Date: Fri, 9 Dec 2011 08:23:14 +0000

Jim,

>in just the straight RADIUS AAA world.

I'm not aware of any standardised semantics to convey this either. It
could always be defined, of course, either within the standard or
vendor-specific RADIUS namespaces.

>information

This is certainly reasonable as SAML allows the RP to specify conditions
to authentication requests. Any modern RADIUS implementation would support
this for the RADIUS attribute case today (we have a FreeRADIUS module for
processing SAML requests that could be extended to cover the SAML case
that you describe without much difficulty I believe).

You also have a third option, which is to infer the LoA from the source of
the request. This obviously doesn't help in the case where an RP needs >1
LoA for a particular IdP.

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Josh Howlett <[email-masked]>
Date: Fri, 9 Dec 2011 08:44:44 +0000

>need to look at that interface more closely?

Assuming that the request were able to convey AAA or SAML semantics
indicating the LoA requirement, I think it is reasonable to expect the IdP
domain to apply policy on these semantics for a single IdP NAI realm.

Josh.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Fri, 09 Dec 2011 09:50:36 +0100

On 9 Dec 2011, at 09:23 , Josh Howlett wrote:
>> 1.  The data is carried in a RADIUS attribute.
> . . .
>> 2.  The data could be carried in a SAML request.
> . . .

I don't think these options are mutually exclusive. The AAA server can have some local policy requiring a particular LoA for specific RPs. If there is no matching local policy rule on this, it can look for a value of a particular RADIUS attribute. If the attribute is not present, or even set to a value explicitly indicating to use the SAML  assertion, it can go that way.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:      +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Dec 2011 08:02:00 -0500

At least in the Moonshot implementation we plan on handling this through
the Communities of Interest concept in draft-mrw-abfab-trust-router.
As Hannes points out LOA really implies more of a system concept than
just how the user is authenticated.
So, some proxies may not be up to carrying particular LOA traffic.

So a particular request would enter the system in a community with a
particular LOA requirement.  That would influence which proxies were
considered appropriate and potentially keying between proxies.

In some cases there may be a RADIUS hop before trust router starts, or
RADIUS hops that carry multiple COIs, similar to how other labeled
traffic is handled.  We'd need some sort of RADIUS attribute for
distinguishing COI in this case.

Obviously, this is very specific to our implementation at the moment,
and we don't have code for this yet.  However it very much is a system
property and so aspects of this are easier to think of in a system
context like Moonshot than purely in a standardization context in order
to see how it all fits together.
Obviously it would be great to standardize as much of this as possible.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 09 Dec 2011 14:18:49 +0100

On 12/09/2011 09:13 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> Hi Jim,
> 
> Here is the challenge with the level of assurance concept: they are
> not just a matter of how the user was authenticated but the
> different levels are reflected in the overall system design.

If you read 800-63 or iso29115 or the Kantara IAF (or most other
trust frameworks sired from 800-63) you will find 4 aspects over
which loa is measured: business maturity and stability, identity
proofing, credentials management and authentication.

It is a common misstake to assume that authentication is the
only aspect.

> 
> As such, it is not sufficient to just communicate from the IdP to
> the RP that a specific transaction is, for example, LoA 4. The RP
> should "know" that since the entire system has to be designed in
> such a way and the IdP and the RP are likely to have an agreement
> (out of band) to ensure the RP that the IdP does actually what it
> is claiming to do.  (You may call this "trust relationship".)
> 

Absolutely not. In most real-world situations LoA is "mixed" - users
may authenticate with different tokens for the same "identity" thus
having different "aggregate" LoA for any given authn event.

You *absolutely* have to figure out a way to communicate LoA and
both SAML and OpenID Connect have mechanisms for this.

> Having said that NIST SP 800-63 (as it is available today;
> revision pending) has a serious shortcoming. It focuses with the
> LoA concept heavily on identity proofing and authentication but
> does not consider the attribute assurance and privacy concepts that
> are associated with the release of data. In a complete system, like
> we are working on in ABFAB, this is very relevant.

This is an area that is seeing increased interest in both OIX and
Kantara for instance. However it may be that the gap are not
as great as one might think.

	Cheers Leif

---

From: Josh Howlett <[email-masked]>
Date: Fri, 9 Dec 2011 15:33:29 +0000

>the Communities of Interest concept in draft-mrw-abfab-trust-router.

Its interesting that Jim has a use case for the multiple communities of
interest problem, and so perhaps we can feed this into the 'problem
statement' document that was proposed in Taipei. Jim: do you have a fuller
description of the requirement (I assume this is rooted in a Plasma use
case?), perhaps taking in policy requirements other than LoA?

Josh.

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 9 Dec 2011 19:46:16 +0000

>what the values mean.  But I still potentially want to do the selection

Note that this is definitely non-trivial, and creates a lot of deployment
complexity when you deal with IdPs that support multiple (or the absence
of) LOAs, and the reality that many RPs need different LOAs to perform
different functions, often from a single client.

In practice, the support in SAML for this has been poorly implemented, or
not at all, and there's not much deployment experience with it.

-- Scott

---

From: Gabriel López <[email-masked]>
Date: Sat, 10 Dec 2011 09:16:28 +0100

> not at all, and there's not much deployment experience with it.

Hi,

We made some work some time ago, in the context of the DAMe project, you
can find some information here:

http://www.item.ntnu.no/europki08/presentations/europki08-lopez.ppt

of course, it is out of date, take it like related work

regards, Gabi.

-- 
----------------------------------------------------------------
Gabriel Lpez Milln
Departamento de Ingeniera de la Informacin y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]