RE: Contradictory requirements?

[Tim Moses <tim.moses@entrust.com>]

Title: RE: Contradictory requirements?

Colleagues - I would like SAML to standardize protocol profiles that enable daisy-chained single-sign-on and application-chain scenarios for the standard commercial browser that do not require the final relying party to know of and trust every link in the daisy-chain.  I believe this will involve each relying party redirecting the browser to the original asserting party, either directly or via its own local authority (for the inter-domain case).  Such a solution would be consistent with my interpretation of the requirements, with the exception of the second sentence in [R-Intermediaries].  Would others consider such a profile to be in or out of scope?  Best regards.  Tim.

-----Original Message-----
From: Mishra, Prateek [mailto:pmishra@netegrity.com]
Sent: Tuesday, June 19, 2001 6:45 PM
To: 'Tim Moses'
Cc: 'security-services@lists.oasis-open.org'
Subject: RE: Contradictory requirements?

Tim,
 
[R-Intermediaries] and [R-Multidomain] as stated suggest that SAML should
support
certain important functionalities. I see no contradiction between them and
the profiles
as written in draft-sstc-bindings-model-04.htm.

Certainly, the web browser profile supports [R-Multidomain]
as it calls out a secure way of binding an assertion to a user and
transferring it from a
source site to a destination site (each may belong to distinct zones of
security administration). 
 
The web browser profile precisely implements (portions of) Use-Case 1:
Single
Sign-On. Evan has pointed out that the profile needs to be widened somewhat
to
cover all of the three sub-scenarios in that use-case 1 (pull, push,
third-party security
service). As written it corresponds tightly to scenario 1-1 (Pull model). We
plan to
address this issue real soon.
 
Use-Case 3 ("application chain") deals with document transfer from one site
to
another. The SOAP profile provides a concrete instance in the context of a
popular messaging protocol.
 
A browser profile that can cope with intermediaries sounds challenging to
me.
Certainly, we could develop one if there is interest in it. One of the ideas
in draft-sstc-bindings-model-04 is that a framework for registering
different
profiles/bindings is provided and that new profiles can be developed and
registered as needed.
 
 
- prateek
 
 
 -----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Tuesday, June 19, 2001 1:15 PM
To: 'Mishra, Prateek'; Tim Moses; 'OASIS Security Services group'
Subject: RE: Contradictory requirements?

Prateek - Does this mean that the "standard commercial browsers" profile
does not satisfy the [R-Intermediates] and [R-MultiDomain] requirements and
the "single-sign-on", "third-party security service" and "application chain"
scenarios?  Best regards.  Tim.

-----Original Message-----
From: Mishra, Prateek [ mailto:pmishra@netegrity.com
<mailto:pmishra@netegrity.com> ]
Sent: Tuesday, June 19, 2001 10:23 AM
To: 'Tim Moses'; 'OASIS Security Services group'
Subject: RE: Contradictory requirements?

Tim,
 
an attempt has been made to address some of the issues in the bindings
document.
 
Briefly, support for intermediaries is a property of a specific profile or
protocol binding.
The web browser profile, for example, does not permit any intermediaries:
users MUST transit directly from an AP to a RP and the token semantics are
specific to (AP, RP) pairs.
 
Those profiles/bindings that permit the use of (untrusted) intermediaries
must explain
how the assertions are protected against misuse through tampering or
impersonation. In some cases, confidentiality may also be required and this
generates another level of
requirement on the profile/binding.
 
In the SOAP profile, for example, intermediaries are permitted. The concept
of
attachment integrity of assertions is introduced precisely to support an
end-to-end
security model (only the original "holder" of the assertions could have
attached them
to the document). This still leaves the question of confidentiality open:
until we have
the XML-encryption specification in hand, we cant mandate the use of
encryption just for
assertion elements.
 
I am not sure we need to worry about "trusted" intermediaries. My thinking
would
be that all "interesting" intermediaries are untrusted. Maybe the language
of [R-Confidentiality] needs to be revised.
 
- prateek
 

-----Original Message-----
From: Tim Moses [ mailto:tim.moses@entrust.com
<mailto:tim.moses@entrust.com> ]
Sent: Tuesday, June 19, 2001 9:00 AM
To: 'OASIS Security Services group'
Subject: Contradictory requirements?

Colleagues - Here are some excerpts from our requirements documents, with
commentary ...

"[R-Bindings] ... SAML should define bindings ... to ... the following
protocols: standard commercial browsers ..."

 - This suggests a "token-style" authentication scheme as described in
draft-sstc-bindings-model-04.doc, Section 3.1.

"[R-Confidentiality] SAML data should be protected from observation by ...
untrusted intermediaries."

 - This suggests that intermediaries may be of two types: trusted and
untrusted.

"[R-Intermediaries] SAML data ... will be structured in a way that they can
be passed from an asserting party through one or more intermediaries to a
relying party.  The validity of the message or assertion can be established
without requiring a direct connection between the asserting and relying
parties."

 - This prompts a number of questions:

"Are the intermediaries referred to of the trusted or untrusted type?"  I
assume that (in order to satisfy the "single-sign-on", "third-party security

service" and "application chain" scenarios) the intermediaries referred to
must have access to the contents of messages and assertions.  But, must the
ultimate relying party trust them not to deliberately, or accidentally,
impersonate the principal, or cause another browser to impersonate the
principal?

The scenarios referred to in the last paragraph are written in terms of
chains with a single intermediary.  But, the requirement includes the phrase

"one or more".  So, should we think of the scenarios as just a special case
of the more general requirement in which chains may contain many
intermediaries?

If intermediaries have to be of the trusted type, then how will a relying
party tell what intermediaries have handled the token and whether or not
they should be trusted? 

If intermediaries may be of the untrusted type, then it seems unlikely that
we will find a solution that can satisfy both the [R-Intermediaries] and the

[R-Bindings] requirements.  We may have to remove the second sentence of the

[R-Intermediaries] requirement.

Thoughts anyone?  Best regards.  Tim.

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

-----------
Tim Moses
Tel: 613.270.3183