> -----Original Message----- > From: Gabriel López [mailto:[email protected]] > Sent: Monday, February 20, 2012 4:26 AM > To: Jim Schaad > Cc: [email protected] > Subject: Re: [abfab] Dual authentication > > > 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.
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 : > > 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 : > >> 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 protected]] > >>> Sent: Saturday, February 18, 2012 11:29 AM > >>> To: Jim Schaad > >>> Cc: [email protected] > >>> Subject: Re: [abfab] Dual authentication > >>> > >>> The current EAP tunnel draft supports multiple authentications. > >>> One intent for that is both for device and user authentication. > >>> Is that good enough? > >> _______________________________________________ > >> abfab mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/abfab > > > > > -- > ---------------------------------------------------------------- > 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 protected] _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
