OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [Action - Gil]: To make a proposal on the mandatory use of HTTPS



Prateek,

I guess I have multiple reactions to this:

(1) Part of the point of making confidentiality protection optional is that
if you have secure
     underlying transport (i.e. VPN or IPSEC) then HTTPS confidentiality is
superfluous
     and a performance hit -- and the artifacts and assertions are
protected against the
     attacks you cite.

(2) The assertions can in any case often be protected by a variety of
means, including
     audience restrictions and subject confirmation.  When these are
sufficient to
     protect the assertion against misuse, no transport-level
confidentiality is
     necessary.  This is NOT true of artifacts.

My preference is for the text to say that implementations SHOULD use
confidentiality at the
transport level if (1) threats are believed to exist in the environment,
(2) confidentiality isn't
provided by a level of the architecture below the implementation (e.g. an
IPSEC VPN),
and (3) the measures in audience restrictions and subject confirmation do
not defeat all
the identified threats.

If one or more of these conditions is not true, then implementations MAY
choose not to
implement confidentiality.

If an implementation chooses to implement confidentiality, then it MUST
implement
HTTPS, and it MAY implement other mechanisms.

How's that?

--bob

Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security and Privacy, Tivoli Systems, Inc.


"Mishra, Prateek" <pmishra@netegrity.com> on 09/25/2001 04:57:25 PM

To:   "'security-services@lists.oasis-open.org'"
      <security-services@lists.oasis-open.org>
cc:   "'Irving.Reid@baltimore.com'" <Irving.Reid@baltimore.com>
Subject:  [Action - Gil]: To make a proposal on the mandatory use of HTTPS



All,

I am struggling with this action item. The issue originates
from the mandatory use of HTTP(S) in 4.1.4.1 (SAML Artifact)
and 4.1.4.3 (Form POST) between the browser equipped
user and source and destination sites respectively.
The essential issue therein is
confidentiality of the SAML artifact (4.1.4.1) or SAML assertions
(4.1.4.3).
If we do not use HTTPS, the HTTP traffic between the user and
source or destination can be copied and used
for impersonation.

There was concern at this requirement at the F2F#4 and as Gil
is away the action item has fallen to me. But I am genuinely puzzled
as to how we can move away from this requirement.

(1) Should the text merely state that confidentiality is a requirement
(MUST) (could be met in some unspecified way?) and that HTTPS
MAY be used? I am opposed to this formulation as it is not specific
enough to support inter-operability. How can a pair of sites
collaborate to support the web browser profile if each uses some
arbitrary method for confidentiality?

(2) Another approach would be to require confidentiality (MUST)
and specify HTTPS as a mandatory-to-implement feature.
Those sites that prefer to use some other method for confidentiality
can do so, but all sites must also support HTTPS. This ensures
inter-operability as we can always fall back on HTTPS.

Comments are invited.

- prateek


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC