Subject: RE: security features.... (Re: Facts, please)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 19 Sep 2006 11:14:35 -0700

> From: Harald Alvestrand [mailto:[email-masked]] 
> > I don't disagree. The IETF might first try to design an 
> authentication 
> > feature worth requiring. None of the current options are at all 
> > satisfactory.
> 
> In fact TLS + HTTP Basic Auth is pretty interoperable, secure 
> against quite a few attacks, and widely deployed.
> 
> The requirements needed to be "satisfactory" depend very much 
> on your viewpoint; last week I talked to the guy who 
> implemented Freenigma (PGP for web mailers, 
> http://www.freenigma.com), and he commented that "this will 
> never get past the security gurus in the IETF because it's so 
> simple, people might actually use it".
> 
> That says something frightening about the kind of impression 
> we give to people who work on making usable security. 
> "Usable" needs to be an important component of "satisfactory".

I think the question starts with a false premise, that the security layer should be in HTTP. Since HTTP is the new IP this makes no more sense than having authentication at the IPSEC layer.

The place for the authentication layer is actually HTML and that is out of scope. Moreover there has to be deep level support in the O/S if the authentication layer is going to be robust.

If we take the traditional IETF view of security perfectionism then the only answer on the table is the WS-* based identity metasystem, CardSpace, Higgins etc running on top of trustworthy hardware.

If we take a more pragmatic view (I hope we do) then we accept that we have to have something else on tap that we can use now, OpenID has a lot to offer. 

Regardless of which view we take it is clear that it would be most beneficial if the two approaches were to meet in the middle. Starting the tunnel at both ends at once only save time if the two tunnels actually meet up.

>From a security point of view it is clear to me that neither approach has any bearing on HTTP. Or rather to the extend that it does the bearing is minimal. So I don't see any real purpose in delaying the advance of HTTP to full standard.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 19 Sep 2006 20:35:55 +0200

> I think the question starts with a false premise, that the security layer should be in HTTP. Since HTTP is the new IP this makes no more sense than having authentication at the IPSEC layer.
I think the concept of  "THE security layer" is a false premise. There's 
no shortage of FPs....
> The place for the authentication layer is actually HTML and that is out of scope.
Actually I think Secure HTML (RFC 2659) died for lack of interest, not 
because it was out of scope....
>  Moreover there has to be deep level support in the O/S if the authentication layer is going to be robust.
>
I think the inevitable dread of the inevitably interminable discussion 
of details of indetectable significance among the people who would have 
to carry it forward has more to do with its non-advancement than the 
missing usable security option....

---

From: Sam Hartman <[email-masked]>
Date: Tue, 19 Sep 2006 15:22:29 -0400

>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <[email-masked]> writes:

    >> From: Harald Alvestrand [mailto:[email-masked]] > I don't
    >> disagree. The IETF might first try to design an authentication
    >> > feature worth requiring. None of the current options are at
    >> all > satisfactory.
    >> 
    >> That says something frightening about the kind of impression we
    >> give to people who work on making usable security.  "Usable"
    >> needs to be an important component of "satisfactory".

    Hallam-Baker,> I think the question starts with a false premise,
    Hallam-Baker,> that the security layer should be in HTTP. Since
    Hallam-Baker,> HTTP is the new IP this makes no more sense than
    Hallam-Baker,> having authentication at the IPSEC layer.

For what it's worth, I think there need to be components both at the HTTP and HTML layers.

You want the binding to TLS at the HTTP layer for a number of reasons
including support for DAV, ATOM and other situations where there is no
HTML.  It's also easier to bind across one layer than two.  Finally,
HTML limits you to one round trip.  Sometimes that's undesirable.

However, I think you want the UI, and in the HTML case the
specification of what authentication mechanisms to use to be done in
HTML.

--Sam

---

From: Russ Allbery <[email-masked]>
Date: Tue, 19 Sep 2006 16:12:17 -0700

Hallam-Baker, Phillip <[email-masked]> writes:

> I think the question starts with a false premise, that the security
> layer should be in HTTP. Since HTTP is the new IP this makes no more
> sense than having authentication at the IPSEC layer.

> The place for the authentication layer is actually HTML and that is out
> of scope. Moreover there has to be deep level support in the O/S if the
> authentication layer is going to be robust.

There are reasons to provide security at multiple layers.  Security at the
HTTP layer is better if the purpose is to prevent unauthorized people from
retrieving resources via HTTP.  Security at the HTML layer is better for
some applications where you want to authenticate the server content to the
browser and are trying to prevent phishing.

You may scoff at doing security at the HTTP layer, and yet nearly everyone
who maintains HTTP content that requires authentication does exactly that,
usually by putting more weight on cookies than they were really designed
to bear and sometimes by (ab)using other HTTP headers (cf Negotiate-Auth).
The small handful of exceptions mostly instead do authentication at the
SSL layer (and face significant UI challenges in doing so, unfortunately,
which mostly rule out those solutions except within fairly controlled
communities).

> If we take the traditional IETF view of security perfectionism then the
> only answer on the table is the WS-* based identity metasystem,
> CardSpace, Higgins etc running on top of trustworthy hardware.

I think this is a little silly.  There are much less complex security
solutions that would meet the IETF criteria simply by enabling one to use
SASL or GSS-API for authentication, as can be seen in many other
applications.

HTTP poses special challenges because it's semi-stateless and because it's
in some respects fundamentally split between two symbiotic protocols (HTTP
and TLS) in a more fundamental way that for Internet protocols where TLS
is optional and strong authentication can be achieved without TLS, but
most of the challenges really stem from the fact that it's extremely
widely used, extremely widely deployed, and a very tempting target for
attack.

> From a security point of view it is clear to me that neither approach
> has any bearing on HTTP. Or rather to the extend that it does the
> bearing is minimal. So I don't see any real purpose in delaying the
> advance of HTTP to full standard.

At this point, widespread deployment of HTTP without interoperable
security is water under the bridge, and I agree that it probably doesn't
make a lot of sense to block its advancement towards full standard because
of missed opportunities years ago.  It shares, in other respects, the
features of a full standard, such as extremely high resistance to change.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>