RE: [Action - Gil]: To make a proposal on the mandatory use of HT TPS

[Irving Reid <Irving.Reid@baltimore.com>]

When I raised this question, it was specifically in the context of the
"transfer URLs" in the Web Browser Pull profile, from the bindings-05
document (section 4.1.4.1). As Prateek points out, it also applies to the
Form Post profile (4.1.4.3).

Clearly, there is an attack against the pull profile if it is possible to
intercept or obtain a copy of the SAML artifact, which is passed as a URL
parameter through an HTTP redirection. Sites that care about the security of
this transfer SHOULD implement the transfer URLs as HTTPS to reduce the
chance that the artifact can be stolen.

However, there are thousands of sites on the Internet that do not consider
attacks like this important enough to protect against. They are perfectly
happy to pass authentication tokens in the form of cookies, URL parameters,
hidden form fields, etc. over unencrypted HTTP. I believe that we should
give such sites the option of using HTTP for the transfer URL, if they feel
that the overhead of setting up HTTPS service does not give them value.

There are also sites that protect the transfer in other ways, such as
performing all communication over a "trusted" internal network or VPN.

My preference is for a modified version of Prateek's option (2) below:

Vendors MUST implement support for using HTTPS to protect communication with
the transfer URLs. Vendors SHOULD implement support for HTTP for the
transfer URLs, to support deployments with different confidentiality
requirements.

Deployments SHOULD provide for confidentiality between the browser and the
transfer URLs.

In terms of the wording in the existing document:
http://www.oasis-open.org/committees/security/docs/draft-sstc-bindings-model
-05.pdf

(aside) In my text, I need to write "HTTP over SSLv3 with server-side
certificate" a bunch of times. Do we want to put that as our definition for
HTTPS at the beginning of the document?

For the three paragraphs starting at line 554 (second, third and fourth
paragraphs in section 4.1.4.1):

The user has authenticated to the source web site and subsequently visits an
inter-site transfer URL, with information about the desired target on the
URL query string (Step 1). The inter-site transfer URL on the source web
site redirects the user to a corresponding assertion consumer URL on the
destination web site (Step 2), with the target and one or more SAML
artifacts carried on the URL query string. This redirect causes the user's
browser to access the consumer URL on the destination web site and pass the
SAML artifacts and intended target.

As these steps may be performed over the open Internet, deployments SHOULD
expose the transfer and consumer URLs using HTTP over SSLv3 with server-side
certificate. Otherwise, the artifact(s) returned on Step 2 and passed on
Step 3 will be available in plain text to an attacker. If attackers obtain
the artifact, they may be able to impersonate the user to the destination
site. Vendors MUST implement support for exposing the transfer URLs as HTTP
over SSLv3 with server-side certificate. Vendors SHOULD implement support
for exposing the transfer and consumer URLs as unencrypted HTTP to support
deployments with different confidentiality requirements.


For the paragraph at line 646 (second pg. in 4.1.4.3):

As steps 2, 3 and 4 may be performed over the open Internet, deployments
SHOULD expose the transfer and consumer URLs using HTTP over SSLv3 with
server-side certificate. Otherwise, the SAML assertion(s) returned on Step 2
and passed on Step 4 will be available in plain text to an attacker. If
attackers obtain the assertions, they may be able to impersonate the user to
the destination site. Vendors MUST implement support for exposing the
transfer and consumer URLs as HTTP over SSLv3 with server-side certificate.
Vendors SHOULD implement support for exposing the transfer and consumer URLs
as unencrypted HTTP to support deployments with different confidentiality
requirements.


 - irving - 

> -----Original Message-----
> From: George_Robert_Blakley_III@tivoli.com
> [mailto:George_Robert_Blakley_III@tivoli.com]
> Sent: Wednesday, September 26, 2001 3:16 PM
> To: pmishra@netegrity.com
> Cc: security-services@lists.oasis-open.org; Irving.Reid@baltimore.com
> 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


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.