Next in thread → Next in month →

RE: [security-services] NIST prohibits use of SAML assertions at LOA 4

From
Cahill, Conor P <>
Date
2008-06-30T23:43:02+00:00
ID
Thread
RE: [security-services] NIST prohibits use of SAML assertions at LOA 4
I would say it would include all Bearer tokens (as Paul pointed
out).   The point being that you need to move to something stronger than bearer
subject confirmation (such as holder-of-key).

 

Conor

 

From: John Bradley
[mailto:] 

Sent: Monday, June 30, 2008 4:27 PM

To: Cahill, Conor P

Cc: Paul Madsen; OASIS SSTC

Subject: Re: [security-services] NIST prohibits use of SAML assertions
at LOA 4

 

Conor,

 

Not that I am 100% certain, but I believe this may
also include infocard SAML barrier tokens not just 'browser redirect
SSO systems that rely on bearer tokens'

 

It is only in the case of a auditing m-card that the STS is
passed the RP's cert for end to end encryption.

 

It may be that infocard m-cards are no better if looked at
closely.  

This just came up on the OSIS call today regarding some of
the feature tests.

Just an observation.

 

Regards

=jbradley

 

On 30-Jun-08, at 12:12 PM, Staggs, David (SAIC) wrote:

All

I support Martin's suggestion.  Our organization prefers a standard

approach.  We want to avoid exceptions for LOA 4, if we can.  Please
add

this topic to the SSTC Bi-Weekly Quorum Con-Call meeting agenda.

Best regards

David

David Staggs, JD, CISSP (SAIC)

Veterans Health Administration

Chief Health Informatics Office

Emerging Health Technologies

-----Original Message-----

From: Smith, Martin [mailto:]

Sent: Sunday, June 29, 2008 5:49 PM

To: Paul Madsen; Cahill, Conor P

Cc: ; Eric Tiffany;
Staggs, David (SAIC); OASIS SSTC

Subject: RE: [security-services] NIST prohibits use of SAML assertions

at LOA 4

So, would the TC be willing to provide a comment along the lines of this

thread to NIST? I believe that would be considered carefully, and those

of us in Fed agencies could endorse it. I believe it's important for Fed

agencies to simplify the use of flexible and robust access-control

facilities that use common authZ and authN data -- and eliminate the

need for apps to implement a separate technology to leverage HSPD-12

credentials.  

Thanks,

Martin

Martin F. Smith

Branch Chief, National Security Systems

DHS/I&A/IM 

202 447-3743 desk

202 441-9731 cell

888 272-3610 pager

________________________________

From:

security-services-return-1423-martin.smith=

on behalf of Paul Madsen

Sent: Fri 6/27/2008 7:48 PM

To: Cahill, Conor P

Cc: ; Eric Tiffany;
Staggs, David (SAIC); OASIS SSTC

Subject: Re: [security-services] NIST prohibits use of SAML assertions

at LOA 4

more generally, rather than pick on SAML, the policy should preclude

'browser redirect SSO systems that rely on bearer tokens'

paul

Cahill, Conor P wrote:

Well, it's interpreted in light of the fact that browsers
cannot

 

perform

 

proof operations with SAML assertions. What they want is not
PKI in

general, but PKI between the relying party and the client.
More than

a

bearer token, in other words. There's plenty to be said for
that

 

argument.

 

Yeah, but then they should be saying that they don't allow
the browser

SSO

profile rather than disallowing the assertions.

 

Conor

 

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS
TC that

generates this mail.  You may a link to this group and
all your TCs in

OASIS

at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

 

 

 

 

--

Paul Madsen
           e:paulmadsen
@ ntt-at.com

NTT
                   p:613-482-0432

                      m:613-282-8647

                      aim:PaulMdsn5

                      web:connectid.blogspot.com

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  You may a link to this group and all your TCs in

OASIS

at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  You may a link to this group and all your TCs in
OASIS

at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Next in thread → Next in month →