RE: Contradictory requirements?

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

Title: RE: Contradictory requirements?

Evan - Thanks for the clarification.  I had supposed that Intermediaries came into play in daisy-chain "single-sign-on" or "application chain" scenarios, in which the principal is authenticated to a series of relying parties (intermediaries), without the need to involve the asserting party at each step.  Although the Requirements document does not describe daisy-chained configurations, it doesn't state that they are illegal.

Any protocol profile that relies on token possession for authenticating the principal (e.g. the "standard commercial browser" profile) runs into problems in daisy-chained scenarios, as (without the involvement of the asserting party at each step) an intermediary can impersonate the principal.

There are solutions to this problem, one of which is to make daisy-chaining illegal for token-based authentication (as I believe Prateek is suggesting).  This would be consistent with your clarification of the term "intermediary".  Is this the answer, or do we need protocols to support secure daisy-chaining for token-based authentication?

Best regards.  Tim.

-----Original Message-----
From: Evan Prodromou [mailto:eprodromou@securant.com]
Sent: Tuesday, June 19, 2001 4:00 PM
To: 'OASIS Security Services group'
Subject: Re: Contradictory requirements?

First off, thanks for the interesting discussion.

Now, addressing your comments:

>>>>> "TM" == Tim Moses <tim.moses@entrust.com> writes:

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

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

I think that's a fair statement, although -really- I think the
different types of intermediaries are as follows:

1) Intermediaries that aren't SAML processors in and of
   themselves. For example, a mail server, a Web proxy or a router.

2) Intermediaries that -are- SAML processors. For example, a PEP that
   sends AuthZ Decision requests to a PDP, including authentication
   and authz attribute assertions that it received from a third party.

I agree that perhaps the use of the term "intermediaries" in that
requirement is unfortunate in that it conflates the two ideas. And
perhaps I'm not drawing a good distinction with your trusted/untrusted
dichotomy. After all, if I send some authc assertion to a PEP, I
am trusting the PEP to use the assertion.

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

Let me just point out that the idea behind this was to allow two
parties to use, and reference, a third-party assertion. Another use
would be for SAML queries to go through firewalls, a queuing message
system, or what have you.

Having a messaging protocol where authentication of the sender is
dependent on (say) the IP address gleaned from the underlying
transport protocol is weak and inflexible.

~ESP

--
Evan Prodromou, Senior Architect        eprodromou@securant.com
Securant Technologies, Inc.             415-856-9551