Subject: [abfab] Dual authentication

From: "Jim Schaad" <[email-masked]>
Date: Sat, 18 Feb 2012 10:13:08 -0800

Those that exist in the ether for the Plasma project have suddenly decided
that they would like to see a new capability that I am not sure is doable in
the ABFAB space.  Or rather I think it is partly doable but not complete.

They have decided that in some circumstances they want to validate and get
information about both the user and the computer that is being used by the
client.  It is relatively easy to do the authentication portion using the
TTLS EAP method if both the client and the server know that it needs to be
done.  However, I do not know of any way to do the following:

1.  Have the RP tell the IdP that it wants to have both the client machine
and the client user authenticated.
2.  Allow the RP to send a SAML query to the IdP to get attributes of the
client machine

They also want to be able to get access to a NIA type assessment of the
client machine, but I am doing my best to ignore that for the moment.  I
don't have enough knowledge of NIA to even make a guess if this is a doable
operation.

Jim

---

From: Sam Hartman <[email-masked]>
Date: Sat, 18 Feb 2012 14:29:02 -0500

The current EAP tunnel draft supports multiple authentications.
One intent for that is both for device and user authentication.
Is that good enough?

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 18 Feb 2012 12:03:54 -0800

Can I do a SAML query for attributes about the device?  We can do one for
the user.

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Saturday, February 18, 2012 11:29 AM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [abfab] Dual authentication
>

---

From: Gabriel López <[email-masked]>
Date: Sat, 18 Feb 2012 21:25:52 +0100

You can make use of NEA, http://datatracker.ietf.org/wg/nea/
combined with SAML.

I can send a more elaborate answer on Monday

regards, Gabi.

El 18/02/12 21:03, Jim Schaad escribió:
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

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

---

From: Klaas Wierenga <[email-masked]>
Date: Sat, 18 Feb 2012 22:38:19 +0100

Yes, and if I am not mistaken Josh specced federated nea

Klaas

Sent from my iPad

---

From: Sam Hartman <[email-masked]>
Date: Sat, 18 Feb 2012 20:31:34 -0500

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> Can I do a SAML query for attributes about the device?  We can
    Jim> do one for the user.

Not yet.
If you need it we could specify how to do it.

---

From: Gabriel López <[email-masked]>
Date: Mon, 20 Feb 2012 13:25:57 +0100

Hi,

    Briefly (please correct me if i'm wrong) , NEA/TNC defines two
entities, NEA client (the end user pc/laptod device) and the NEA server
(usually located in the home RADIUS server).
    Transporting NEA/TNC packets over EAP, NEA/TNC peers make a Platform
Credentials Authentication, where the own device is authenticated (note
that the end user has already been authenticated in a previous step).
    Once the device is authenticated, device/server posture attributes
are exchanged and validated. If the server decides device's posture
attributes are ok, then the process ends successfully.

    This scenario presents a problem in a federated AAA network. The
final decision about posture attributes is taken by the home RADIUS
server, which it is not a realistic situation (i.e. visited organization
only provides network connectivity to remote users that have an update
antivirus software running. This decision should be controlled by the
visited organization, not the home one).

    To solve this situation, the Trusted Computing Group defined the
integration of NEA/TNC with SAML
http://www.trustedcomputinggroup.org/files/resource_files/51F4B514-1D09-3519-ADEF8EA701461A74/TNC_Federated_TNC_v1.0-r26.pdf
(sure Josh (co-author) can provide more details)
    The idea of this proposal is to, after the platform authentication,
recover the end user posture attributes, from the home to the visited
organization, by means of SAML Attribute Queries/Responses (in a second
round-trip, once the RADIUS-ACCEPT is sent back to the visited
organization).
    We also proposes a similar approach for eduroam some time ago.

    In the case of abfab, if we want to avoid a second round-trip, those
posture attributes should be collected by the home organization during
the NEA/EAP exchange, posture attributes should be stored (not
evaluated) in the home idP, together or not with the own end user
attributes, and then, sent those back to the visited organization
encapsulated in the SAML attribute statement over the RADIUS protocol.

    regards, Gabi.

---

From: Josh Howlett <[email-masked]>
Date: Mon, 20 Feb 2012 16:28:58 +0000

>the ABFAB space.  Or rather I think it is partly doable but not complete.

I think that is an accurate summary.

>and the client user authenticated.

Abfab certainly doesn't have those semantics. I can't recall if NEA does.
I would be surprised if it did, but I can't imagine it would be difficult
to add (it's probably just a AAA-bound flag?).

>2.  Allow the RP to send a SAML query to the IdP to get attributes of the

You could use either a SOAP-bound or AAA-bound SAML query.

>don't have enough knowledge of NIA to even make a guess if this is a

I can't see a reason why NEA couldn't be used with Abfab today.

You might want to look at the Federated TNC spec; this only addresses your
use case for the web-bound case, but some of concepts might be useful. I
don't think it would be hard to port it to Abfab/NEA.

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: "Jim Schaad" <[email-masked]>
Date: Mon, 20 Feb 2012 14:47:17 -0800

Thanks to both you and Gabriel for response.

> From: Josh Howlett [mailto:[email-masked]]
> Sent: Monday, February 20, 2012 8:29 AM
> To: Jim Schaad; [email-masked]
> >Those that exist in the ether for the Plasma project have suddenly
> >decided that they would like to see a new capability that I am not sure
> >is doable in the ABFAB space.  Or rather I think it is partly doable
> >but not complete.
> 
> >They have decided that in some circumstances they want to validate and
> >get information about both the user and the computer that is being used
> >by the client.  It is relatively easy to do the authentication portion
> >using the TTLS EAP method if both the client and the server know that
> >it needs to be done.  However, I do not know of any way to do the
> following:
> >
> >1.  Have the RP tell the IdP that it wants to have both the client
> >machine and the client user authenticated.
> 
to add
> (it's probably just a AAA-bound flag?).

Except for the question of how to frame the SAML query, I image doing the
SAML query might be sufficient to tell the IdP that a NEA assessment is
desired.  The question would be one of should there be two SAML queries or
one.  If you have two, then how do you distinguish between the client query
and the machine query.  If you have one, then are there any attributes which
might apply to both a user and a machine?

> 
> >2.  Allow the RP to send a SAML query to the IdP to get attributes of
> >the client machine
> 
> >client machine, but I am doing my best to ignore that for the moment.
> >I don't have enough knowledge of NIA to even make a guess if this is a
> >doable operation.
> 

I will have to look at the spec.  I demonstrated my lack of knowledge about
NEA by using the wrong TLA to begin with.  I assume that if you run a TTLS
that the NEA/EAP dialog would be able to occur inside the same tunnel as the
user and machine authentication steps.  I am not sure if that would add
material to the key generation but that is probably not of any importance.  

> 
> 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: "Jim Schaad" <[email-masked]>
Date: Mon, 20 Feb 2012 14:47:38 -0800

> From: Gabriel López [mailto:[email-masked]]
> Sent: Monday, February 20, 2012 4:26 AM
> To: Jim Schaad
> Cc: [email-masked]
>     Briefly (please correct me if i'm wrong) , NEA/TNC defines two entities,
> NEA client (the end user pc/laptod device) and the NEA server (usually
> located in the home RADIUS server).
>     Once the device is authenticated, device/server posture attributes are
> exchanged and validated. If the server decides device's posture attributes
> are ok, then the process ends successfully.
> 
>     This scenario presents a problem in a federated AAA network. The final
> decision about posture attributes is taken by the home RADIUS server, which
> it is not a realistic situation (i.e. visited organization only provides network
> connectivity to remote users that have an update antivirus software running.
> This decision should be controlled by the visited organization, not the home
> one).
> 
> http://www.trustedcomputinggroup.org/files/resource_files/51F4B514-
> 1D09-3519-ADEF8EA701461A74/TNC_Federated_TNC_v1.0-r26.pdf
>     The idea of this proposal is to, after the platform authentication, recover
> the end user posture attributes, from the home to the visited organization,
> by means of SAML Attribute Queries/Responses (in a second round-trip,
> once the RADIUS-ACCEPT is sent back to the visited organization).
> posture attributes should be collected by the home organization during the
> NEA/EAP exchange, posture attributes should be stored (not

I would assume that there might be cases where two different assessments are going to occur.  One for the home idP and one for the RP.  This might mean that that it is a requirement that the RP can send it's needs to the IdP before the posture attributes are collected as they may have somewhat different needs.  Also there might be some issues about mapping of the posture requriements.  However that should be able to be handled via the standard SAML mapping techniques

Jim

> 
>     regards, Gabi.
> 
> 
> 
> El 18/02/12 21:25, Gabriel L pez escribi :
> > El 18/02/12 21:03, Jim Schaad escribi :
> >> Can I do a SAML query for attributes about the device?  We can do one
> >> for the user.
> >>
> Gabriel L?pez Mill?n
> Departamento de Ingenier?a de la Informaci?n y las Comunicaciones
> University of Murcia Spain
> Tel: +34 868888504
> Fax: +34 868884151
> email: [email-masked]

---

From: Josh Howlett <[email-masked]>
Date: Tue, 21 Feb 2012 09:21:04 +0000

>desired.

That's another approach.

>  The question would be one of should there be two SAML queries or

An assertion request can name at most one principal, and so this is most
likely two queries, if you chose to have a model that considered the user
and device to be distinct principals (and so naming them separately). On
the other hand, it might be reasonable to consider the device to be an
attribute of a principal. A lot depends on the detail of the use case. In
any event, I don't think you're going to be particularly constrained by
the capabilities of the existing technology.

>user and machine authentication steps.

Correct.

>  I am not sure if that would add
>material to the key generation

It doesn't.

Josh.

---

From: Gabriel López <[email-masked]>
Date: Tue, 21 Feb 2012 11:37:26 +0100

>> I would be surprised if it did, but I can't imagine it would be difficult
Although NEA specifications do not limit the entity starting the NEA
exchange (client or server). EAP-TNC specifies the server starts the
attributes exchange.
> might apply to both a user and a machine?
I think SAML is not necessary to start the NEA negotiation, the use of
EAP-TNC Start from the RP could be defined in some way.
> user and machine authentication steps. 
sure

regards, Gabi.