Title: Credentials Collector proposal for SAML 2.0...
Regarding Slava's
comment #1 (the notion of hiding permanent credentials from a CC-translator), I
think this is an important issue to consider. From a very
practical point of view, one can divide Authentication Authorities to two
general categories:
a. AA's that need to see
the actual credential (i.e., an LDAP directory that does not expose
the password hash and must "see" the password to authenticate the user),
and
b. AA's that need not
necessarily see the credential to authenticate the user (e.g., any kind of
challenge response protocol, such as Kerberos) .
I believe it is
difficult to fulfill credential-protection when the authentication authority is
in category (a) above, at least with standard off-the-shelf products in this
category.
Jahan
----------------
Jahan Moreh
Chief Security
Architect
310.286.3070
-----Original Message-----
From: Carlisle Adams
[mailto:]
Sent: Tuesday, April 15, 2003
2:42 PM
To: 'Kavsan, Bronislav'
Cc:
''
Subject: RE:
[security-services] Credentials Collector proposal for SAML 2
.0...
Hi
Slava,
Good comments. I
agree that protection of certain authenticators is worth pointing out, even if
we don't solve it in this first round. Also, the concept of an
AA-Validator could be included as a fourth architecture (or as a twist on the
existing ones). What do others think?
Carlisle.
-----Original Message-----
From: Kavsan, Bronislav
[mailto:]
Sent: Thursday, March 13, 2003
7:59 PM
To: 'Carlisle Adams';
''
Subject: RE:
[security-services] Credentials Collector proposal for SAML 2
.0...
Carlisle,
I like the proposal - good start!
Few comments/suggestions:
1. One interesting topic worth considering for the
Discussion or Issues/Requirements section - protection/blinding of certain
types of authenticators from CC in the CC-Translator scenario. In other words - in some deployments, where
CC-Translator and AA are in separate security domains, it is often
undesirable to reveal certain types of authenticators (static shared
secrets, e.g. passwords) to CC-Translator. Such protection may not be needed
for one-time passwords and challenge-response methods. I am not sure how to
accomplish that - it could either
non-standard (Type 2
protocol?) or out-of-SAML-scope topic, but nevertheless, I
think, it is worthwhile
pointing out this issue..
2. Using WS-Trust lingo
- AA can be viewed as
a Security Token Service (STS) with an
interesting scenario of AA/STS being WS-Trust Credential Validatior as it is
described in WS-Trust spec. So, AA-Validator could possibly be
another (fourth) deployment
scenario where CC-Authenticator will invoke
AA-Validator to validate certification path and/or cert revocation status,
for example. Or this scenario could be hybridized with the CC-Authenticator
scenario.
I also support your recommendation for Approach #3 - and RSA
Security, as well as other co-authors of the spec strongly advocating
submission of WS-Trust spec to standards organization.
Thank you,
Slava Kavsan
RSA Security
-----Original Message-----
From: Carlisle Adams
[mailto:]
Sent: Tuesday, March 11,
2003 2:16 PM
To:
''
Subject:
[security-services] Credentials Collector proposal for SAML
2.0...
Hi all,
I've finally gotten around
to updating and filling out the Credentials Collector proposal. I've
tried to take into account the brief discussions a few of us have had so
far on this topic. Further comment/discussion is welcome, on the
list and perhaps in an upcoming concall.
Carlisle.
<<SAML Credentials
Collector.doc>>
