Title: Message
Jahan,
There is another area
that I thought we can discuss over email and that this calling out SSL/TLS in
the proposed profiles. Basically, by using SSL we will prevent a malicious
destination from colluding with a malicious source to steal a user's
credentials. I.e., if the destination redirects the user to a source that
cannot prove authenticity under SSL, then the user should not provide his
uid/password. This is consistent with our current 1.0 browser profiles that
envision source-site-first flow.
<Prateek>
my problem here is that this is
something the user must do: check to verify that the source site is in
fact the site he/she expects it to be and perhaps demand that the site
authenticate itself to the user before presenting credentials to
the site (.e.g, server-side SSL). In other words, this does not have
impact on our steps (1)-(4) but only on the relationship between the user and
the source site. I can note this in the threat and counter-measure section but
I am not sure I can say anything more than that, or, can
I?
</Prateek>
----------------
Jahan Moreh
Chief Security
Architect
310.286.3070
-----Original Message-----
From: Mishra, Prateek
[mailto:]
Sent: Wednesday, March 19, 2003
12:43 PM
To:
''
Subject:
[security-services] sstc-bindings-extensions-02
This documen updates the "Destination Site
First" flows published by Scott Cantor in a
message sent
on
Tuesday, March
18 with Subject:Updated core/bindings with dest site first (no March
archives are available)
I have added a
GET-oriented flow from the destination site to the source site. It follows
Scott's POST-based flows very closely; for some required values I have
chosen fixed-size strings in place of the unbounded strings used in the
POST case. Other than that, the two flows are quite
similar.
-
prateek
sstc-bindings-extensions-02JM.doc
