From ynir@checkpoint.com Tue Jan 1 21:21:16 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7251A21E8042 for ; Tue, 1 Jan 2013 21:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.514 X-Spam-Level: X-Spam-Status: No, score=-10.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Eu9EhCCD5Aj for ; Tue, 1 Jan 2013 21:21:15 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F318E21E8049 for ; Tue, 1 Jan 2013 21:21:14 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r025L8bN027052; Wed, 2 Jan 2013 07:21:08 +0200 X-CheckPoint: {50E3C211-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.22]) by IL-EX10.ad.checkpoint.com ([169.254.2.238]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 07:21:08 +0200 From: Yoav Nir To: IETF WebSec WG Thread-Topic: Proposed Work Item: Session Continuation Thread-Index: AQHN6Kj4TGrWm5x6LkCXvy4676ba+g== Date: Wed, 2 Jan 2013 05:21:08 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277210EE20E90@IL-EX10.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.253] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <761F2CE1AA47D84DBB34ECE4BDC28F4B@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Yaron Sheffer Subject: [websec] Proposed Work Item: Session Continuation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 05:21:16 -0000 Hi all Some of you may have attended the HTTPAuth BoF in Atlanta. That BoF was not= successful in forming a working group, but one of the take-aways from that= meeting was that a better session management protocol was both needed, and= something the IETF could do decent work on. This is partially motivated by= the recent BEAST and CRIME attacks, which relied on the repeated transmiss= ion of the session cookie, and in another part by the realization that the = use of HTTP cookies to manage sessions as it is done today is unsound. In the last few weeks, a design team has been working on a problem statemen= t document. The design team includes Nico Williams, Phillip Hallam-Baker, Y= aron Sheffer, and Paul Leach. The draft is by no means finished, but we thi= nk it is ready to go public for discussion on this list. Here's a link to the draft: http://tools.ietf.org/html/draft-williams-websec-session-continue-prob-00 It should be noted that this document and a possible subsequent protocol do= cument are NOT currently on the WebSec charter. Only X-Frame-Options and Ke= y Pinning are. But we do think this list is a good venue for this item, and= if there's enough interest we can ask our AD to add this to our charter. If accepted, the problem statement should be followed by a protocol documen= t, and perhaps by a client practices document. But that's for the future. T= he design team has also been working on a proposed session continuation pro= tocol document[1], but that is in a more initial state, and (with chair hat= on) we will consider it among other possible proposals when the time comes= . I'd like to thank the design team members for this work, and especially Nic= o Williams for editing the problem statement document.=20 Regards, Yoav [1] http://tools.ietf.org/html/draft-williams-websec-session-continue-proto= -00= From ynir@checkpoint.com Mon Jan 14 09:05:34 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5422821F8A0C for ; Mon, 14 Jan 2013 09:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMPMh4KxKbQW for ; Mon, 14 Jan 2013 09:05:33 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0E421F8919 for ; Mon, 14 Jan 2013 09:05:33 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r0EH5W9E018632 for ; Mon, 14 Jan 2013 19:05:32 +0200 X-CheckPoint: {50F43872-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([fe80::80df:1c2c:3d29:3748%11]) with mapi id 14.02.0328.009; Mon, 14 Jan 2013 19:05:32 +0200 From: Yoav Nir To: IETF WebSec WG Thread-Topic: Forwarded review of draft-williams-websec-session-continue-prob-00 Thread-Index: AQHN8nlcmIC/Qj7GzkKmO9jrZVrmlg== Date: Mon, 14 Jan 2013 17:05:31 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772111983941@IL-EX10.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] Content-Type: text/plain; charset="us-ascii" Content-ID: <80962A1D89D89347BBEEFE6D760A5BB9@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] Forwarded review of draft-williams-websec-session-continue-prob-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:05:34 -0000 Hi I've shown this draft to a co-worker of mine (not on this list), and asked = for a review. Here's some comments: - Overall, this is an interesting problem.=20 - The document is missing a list of deficiencies with using Cookies - Section 2.1 says that TLS protects against replay. Really? How? It doesn= 't have a protected counter like IPsec. - Will the resulting protocol support a transition from authenticated sessi= on to authenticated session for purposes such as re-authenticating after a = specified time, or moving from weak authentication to strong authentication= for high-value transactions. Nit: HTTP is HyperText **Transfer** Protocol, not **Transport*. This one i= s already fixed in Nico's repository. Yoav= From jasnell@gmail.com Mon Jan 14 13:36:50 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B35721F8B3A for ; Mon, 14 Jan 2013 13:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[AWL=-2.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q48RRg-bcBSZ for ; Mon, 14 Jan 2013 13:36:49 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 872C221F8B0C for ; Mon, 14 Jan 2013 13:36:49 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id c10so5828109ieb.39 for ; Mon, 14 Jan 2013 13:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=aj/5n1qLcXSc5ReTgRgFenuZ8GFEr6h4VT6r7X54Hf8=; b=1FIsKCzIe8oPbkDFjHFMQhoeiea8o9euU+lcIobi/PdffiyrzpbeTba5zDCN7FnRGv l8jqpXwgpG8flPdRFWc/U2UULX/QXmNRGVLwIavFxY3Jnqw+d2qaZADlQ7r/LtPbm1fx bMMjw1V+YecHZPocK3rGp/UZ+TvH//qBf8nz3yefikaAXxG25c2jdp69TBQHqFYtVnY9 vd8oBa7WEnKqh8dZKGJWBS8w/wxcMXZFgj3h9Bvlnm0EM0s2QTw4nSlDv+gswMxLRJ6+ Ya4fZqfezSYga/W6aq5yEJAFTTULvCn+br9Vk3rtHSjTp0KZ4fUstYxyt51LcCxY9wNE KSBw== Received: by 10.50.158.170 with SMTP id wv10mr8184789igb.75.1358199409069; Mon, 14 Jan 2013 13:36:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.26.137 with HTTP; Mon, 14 Jan 2013 13:36:28 -0800 (PST) From: James M Snell Date: Mon, 14 Jan 2013 13:36:28 -0800 Message-ID: To: websec@ietf.org Content-Type: multipart/alternative; boundary=14dae9340f214fce5b04d346712b Subject: [websec] draft-williams-websec-session-continue-prob-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 21:36:50 -0000 --14dae9340f214fce5b04d346712b Content-Type: text/plain; charset=UTF-8 Hello, Just jumped over here from the http list per Yoav Nir's request for feedback with regards to the draft-williams-websec-session-continue-prob draft. Overall I think the draft is a good start. There definitely does need to be more of an explanation as to why the existing cookie-based mechanism is bad. As far as more forward looking feedback is concerned, I wanted to point to the In-Session Key Negotiation draft I wrote as input to the ongoing http/2 discussion http://tools.ietf.org/html/draft-snell-httpbis-keynego-00 This draft introduces a new (currently experimental) bidirectional key-negotiation sub-protocol within spdy/http2 for the negotiation of secure keys and can be used for the establishment of authenticated and unauthenticated sessions. (Note that I'm just making sure folks know about this draft as it is relevant to the discussion)... Running down through the list of requirements stated by the websec-session-continue-prob draft it covers a good deal of the issues. - James --14dae9340f214fce5b04d346712b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Just jumped over here from the http list per Yoav N= ir's request for feedback with regards to the=C2=A0draft-williams-websec-session-continue-prob draft.= =C2=A0

Overall I think the draft is a good= start. There definitely does need to be more of an explanation as to why t= he existing cookie-based mechanism is bad.

As far as more forward looking feed= back is concerned, I wanted to point to the In-Session Key Negotiation draf= t I wrote as input to the ongoing http/2 discussion


This draft introduces a new (currently experim= ental) bidirectional key-negotiation sub-protocol within spdy/http2 for the= negotiation of secure keys and can be used for the establishment of authen= ticated and unauthenticated sessions.=C2=A0(Note that I'm just making sure folks know about this draf= t as it is relevant to the discussion)...=C2=A0Running down through the list of req= uirements stated by the websec-session-continue-prob draft it covers a good= deal of the issues.

=
- James
--14dae9340f214fce5b04d346712b-- From ynir@checkpoint.com Tue Jan 15 06:04:25 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1001621F87D9 for ; Tue, 15 Jan 2013 06:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.765 X-Spam-Level: X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCLqtMtAc5H9 for ; Tue, 15 Jan 2013 06:04:24 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9143121F873E for ; Tue, 15 Jan 2013 06:04:23 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r0FE4KJL015428; Tue, 15 Jan 2013 16:04:20 +0200 X-CheckPoint: {50F55F6D-3-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([fe80::80df:1c2c:3d29:3748%11]) with mapi id 14.02.0328.009; Tue, 15 Jan 2013 16:04:20 +0200 From: Yoav Nir To: James M Snell Thread-Topic: [websec] draft-williams-websec-session-continue-prob-00 Thread-Index: AQHN8p9I7Of/xGWYU0m2QufJ2qbPJ5hKS6iA Date: Tue, 15 Jan 2013 14:04:19 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772111984CB4@IL-EX10.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] Content-Type: multipart/alternative; boundary="_000_4613980CFC78314ABFD7F85CC302772111984CB4ILEX10adcheckpo_" MIME-Version: 1.0 Cc: "" Subject: Re: [websec] draft-williams-websec-session-continue-prob-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 14:04:25 -0000 --_000_4613980CFC78314ABFD7F85CC302772111984CB4ILEX10adcheckpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi James I've now read your draft. It looks to solve the same kind of problem as PHB= 's integrity draft [1], although that one currently uses HTTP/1 syntax. The protocol you propose binds a key to a session (or "KEY-ID") and this al= lows to integrity protect both requests and responses. It also allows the c= lient to bind specific requests to specific sessions, which is one of the r= equirements in the session-continue draft. Integrity protection of the requ= ests (an possibly responses) is definitely a key component of any solution = to make sessions secure. It doesn't help to authenticate just the fact that= there is a request, if we then allow a proxy to rewrite the entire content= of the request. What's missing for me is a binding of that key-id to an authenticated ident= ity. Identities can be authenticated multiple ways. There's the user certif= icate in TLS, Some better or worse HTTP schemes (everything from Basic to Z= KPPs), two-factor methods using some side-channel (such as instant messagin= g to mobile phones), and even HTTP forms, whether they are the insecure kin= d we use today or something with browser-based encryption. I think it would= be a worthy goal to have all of these bind somehow to the key-id. The other thing that's missing, but should probably be in a separate docume= nt (that I think we're not ready to start yet) is a specification of client= behavior, meaning when should the client use the same session id (or "key = id") for different requests. For example, if I have gmail open in one brows= er tab, and in another tab I have a site, where teh HTML says "">", should the request to mail.google.com = use the same key id that I am using with GMail? The one that is bound to m= y identity? With the current cookie mechanism, the answer is yes. If we def= ine a new session mechanism, we can re-think this. Yoav [1] http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02 On Jan 14, 2013, at 11:36 PM, James M Snell > wrote: Hello, Just jumped over here from the http list per Yoav Nir's request for feedbac= k with regards to the draft-williams-websec-session-continue-prob draft. Overall I think the draft is a good start. There definitely does need to be= more of an explanation as to why the existing cookie-based mechanism is ba= d. As far as more forward looking feedback is concerned, I wanted to point to = the In-Session Key Negotiation draft I wrote as input to the ongoing http/2= discussion http://tools.ietf.org/html/draft-snell-httpbis-keynego-00 This draft introduces a new (currently experimental) bidirectional key-nego= tiation sub-protocol within spdy/http2 for the negotiation of secure keys a= nd can be used for the establishment of authenticated and unauthenticated s= essions. (Note that I'm just making sure folks know about this draft as it = is relevant to the discussion)... Running down through the list of requirem= ents stated by the websec-session-continue-prob draft it covers a good deal= of the issues. - James --_000_4613980CFC78314ABFD7F85CC302772111984CB4ILEX10adcheckpo_ Content-Type: text/html; charset="us-ascii" Content-ID: <38F23EA31B9B7247AA2DACCDFCFBAFDF@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi James

I've now read your draft. It looks to solve the same kind of problem a= s PHB's integrity draft [1], although that one currently uses HTTP/1 syntax= . 

The protocol you propose binds a key to a session (or "KEY-ID&quo= t;) and this allows to integrity protect both requests and responses. It al= so allows the client to bind specific requests to specific sessions, which = is one of the requirements in the session-continue draft. Integrity protection of the requests (an possibly responses) is def= initely a key component of any solution to make sessions secure. It doesn't= help to authenticate just the fact that there is a request, if we then all= ow a proxy to rewrite the entire content of the request.

What's missing for me is a binding of that key-id to an authenticated = identity. Identities can be authenticated multiple ways. There's the user c= ertificate in TLS, Some better or worse HTTP schemes (everything from Basic= to ZKPPs), two-factor methods using some side-channel (such as instant messaging to mobile phones), and even H= TTP forms, whether they are the insecure kind we use today or something wit= h browser-based encryption. I think it would be a worthy goal to have all o= f these bind somehow to the key-id.

The other thing that's missing, but should probably be in a separate d= ocument (that I think we're not ready to start yet) is a specification of c= lient behavior, meaning when should the client use the same session id (or = "key id") for different requests. For example, if I have gmail open in one browser tab, and in another tab I= have a site, where teh HTML says "<img src=3D"mail.google.com/imgs/yellow_arrow= .gif">", should the request to mail.google.com use the same key id = that I am using with GMail?  The one that is bound to my identity? Wit= h the current cookie mechanism, the answer is yes. If we define a new sessi= on mechanism, we can re-think this.

Yoav


Hello,

Just jumped over here = from the http list per Yoav Nir's request for feedback with regards to the&= nbsp;draft-williams-websec-ses= sion-continue-prob draft. 

Overall I think the d= raft is a good start. There definitely does need to be more of an explanati= on as to why the existing cookie-based mechanism is bad.

As far as more forwar= d looking feedback is concerned, I wanted to point to the In-Session Key Ne= gotiation draft I wrote as input to the ongoing http/2 discussion


This draft introduces= a new (currently experimental) bidirectional key-negotiation sub-protocol = within spdy/http2 for the negotiation of secure keys and can be used for th= e establishment of authenticated and unauthenticated sessions. Running down through the list of requirements stated by the websec-session-continue-prob draft it covers= a good deal of the issues.

- James=

--_000_4613980CFC78314ABFD7F85CC302772111984CB4ILEX10adcheckpo_-- From jasnell@gmail.com Tue Jan 15 08:05:14 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F6721F8757 for ; Tue, 15 Jan 2013 08:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.416 X-Spam-Level: X-Spam-Status: No, score=-4.416 tagged_above=-999 required=5 tests=[AWL=-2.484, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCZOqax2k6y9 for ; Tue, 15 Jan 2013 08:05:13 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id E24E121F8632 for ; Tue, 15 Jan 2013 08:05:12 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c12so452366ieb.23 for ; Tue, 15 Jan 2013 08:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FPSmQfbLzhkSZsDyaIcBFYMH4+jZHC72FJ9YtZVc4+g=; b=e2KkFaX/kaPMHCkQqBmbBuAAvWwOukoxv32XXdv4+6YixEo4at4MIOVlFStXpXax7S bQ2Vtlv8ZyUq/k+X+kOHj7ikV9cO2kiKvllfcpaomZJxvhZTJrJI9XW4nYDrWbKr3sPi FZHXDwaHm30n+PUYf3KColUBNEP0IvjsnnFQpiMw0R1FOKhsP2cYKr0JOgOd1nWUGGQN P9EujZbZPS+TeYCMxUs80s1JT7HElQezgQKak3Qwi7QgQs7xLvlG9OgVa3ZoK4Hyouca Og/gvwsUtFLL0ZjiFwsu8sqJTPH1HDVK7lq7EK1op97QU0GamesPS3ekzpG97cA1CxYo nZDg== Received: by 10.50.196.227 with SMTP id ip3mr1974642igc.97.1358265912462; Tue, 15 Jan 2013 08:05:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.26.137 with HTTP; Tue, 15 Jan 2013 08:04:52 -0800 (PST) In-Reply-To: <4613980CFC78314ABFD7F85CC302772111984CB4@IL-EX10.ad.checkpoint.com> References: <4613980CFC78314ABFD7F85CC302772111984CB4@IL-EX10.ad.checkpoint.com> From: James M Snell Date: Tue, 15 Jan 2013 08:04:52 -0800 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=14dae934117b390c3104d355ed96 Cc: "" Subject: Re: [websec] draft-williams-websec-session-continue-prob-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:05:14 -0000 --14dae934117b390c3104d355ed96 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 15, 2013 at 6:04 AM, Yoav Nir wrote: > Hi James > > I've now read your draft. It looks to solve the same kind of problem as > PHB's integrity draft [1], although that one currently uses HTTP/1 syntax. > > There is definitely overlap in the use of the integrity frame. Once http/2 is down the road a bit and I see how things evolve there I hope to work with PHB to reconcile the two mechanisms. > The protocol you propose binds a key to a session (or "KEY-ID") and this > allows to integrity protect both requests and responses. It also allows the > client to bind specific requests to specific sessions, which is one of the > requirements in the session-continue draft. Integrity protection of the > requests (an possibly responses) is definitely a key component of any > solution to make sessions secure. It doesn't help to authenticate just the > fact that there is a request, if we then allow a proxy to rewrite the > entire content of the request. > > Correct.. the original use case for my spec was for key negotiation for encryption of individual spdy frames and establishment authenticated credentials. It can, however, be leveraged for a broader set of cases but there are certainly details that would need to be ironed out (not the least of which is how these manifest within the http/2 framing layer which is going to take quite some time to figure out) > What's missing for me is a binding of that key-id to an authenticated > identity. Identities can be authenticated multiple ways. There's the user > certificate in TLS, Some better or worse HTTP schemes (everything from > Basic to ZKPPs), two-factor methods using some side-channel (such as > instant messaging to mobile phones), and even HTTP forms, whether they are > the insecure kind we use today or something with browser-based encryption. > I think it would be a worthy goal to have all of these bind somehow to the > key-id. > > Agreed. That's something I'll be looking at. The keynego frames themselves allow for a range of protocols for establishing a key, and multiple keys can be negotiated for a single session. For instance, we can have a keynego exchange that authenticates both the client and servers identities and establishes a shared secret key that is then used to encrypt the individual frames in the stream. Again tho, this is very preliminary and there are many details to work out. At this step, I largely just wanted to make sure people were aware of the draft as the discussion moves forward. > The other thing that's missing, but should probably be in a separate > document (that I think we're not ready to start yet) is a specification of > client behavior, meaning when should the client use the same session id (or > "key id") for different requests. For example, if I have gmail open in one > browser tab, and in another tab I have a site, where teh HTML says " src="mail.google.com/imgs/yellow_arrow.gif">", should the request to > mail.google.com use the same key id that I am using with GMail? The one > that is bound to my identity? With the current cookie mechanism, the answer > is yes. If we define a new session mechanism, we can re-think this. > > Agreed. - James > Yoav > [1] http://tools.ietf.org/html/draft-hallambaker-httpintegrity-02 > > On Jan 14, 2013, at 11:36 PM, James M Snell wrote: > > Hello, > > Just jumped over here from the http list per Yoav Nir's request for > feedback with regards to the draft-williams-websec-session-continue-prob > draft. > > Overall I think the draft is a good start. There definitely does need to > be more of an explanation as to why the existing cookie-based mechanism is > bad. > > As far as more forward looking feedback is concerned, I wanted to point > to the In-Session Key Negotiation draft I wrote as input to the ongoing > http/2 discussion > > http://tools.ietf.org/html/draft-snell-httpbis-keynego-00 > > This draft introduces a new (currently experimental) bidirectional > key-negotiation sub-protocol within spdy/http2 for the negotiation of > secure keys and can be used for the establishment of authenticated and > unauthenticated sessions. (Note that I'm just making sure folks know > about this draft as it is relevant to the discussion)... Running down > through the list of requirements stated by the websec-session-continue-prob > draft it covers a good deal of the issues. > > - James > > > --14dae934117b390c3104d355ed96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jan 15, 2013 at= 6:04 AM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi James

I've now read your draft. It looks to solve the same kind of probl= em as PHB's integrity draft [1], although that one currently uses HTTP/= 1 syntax.=C2=A0


There is defini= tely overlap in the use of the integrity frame. Once http/2 is down the roa= d a bit and I see how things evolve there I hope to work with PHB to reconc= ile the two mechanisms.=C2=A0
=C2=A0
The protocol you propose binds a key to a session (or "KEY-ID&quo= t;) and this allows to integrity protect both requests and responses. It al= so allows the client to bind specific requests to specific sessions, which = is one of the requirements in the session-continue draft. Integrity protection of the requests (an possibly responses) is def= initely a key component of any solution to make sessions secure. It doesn&#= 39;t help to authenticate just the fact that there is a request, if we then= allow a proxy to rewrite the entire content of the request.


Correct.. the o= riginal use case for my spec was for key negotiation for encryption of indi= vidual spdy frames and establishment authenticated credentials. It can, how= ever, be leveraged for a broader set of cases but there are certainly detai= ls that would need to be ironed out (not the least of which is how these ma= nifest within the http/2 framing layer which is going to take quite some ti= me to figure out)
=C2=A0
What's missing for me is a binding of that key-id to an authentica= ted identity. Identities can be authenticated multiple ways. There's th= e user certificate in TLS, Some better or worse HTTP schemes (everything fr= om Basic to ZKPPs), two-factor methods using some side-channel (such as instant messaging to mobile phones), and even H= TTP forms, whether they are the insecure kind we use today or something wit= h browser-based encryption. I think it would be a worthy goal to have all o= f these bind somehow to the key-id.


Agreed. That= 9;s something I'll be looking at. The keynego frames themselves allow f= or a range of protocols for establishing a key, and multiple keys can be ne= gotiated for a single session. For instance, we can have a keynego exchange= that authenticates both the client and servers identities and establishes = a shared secret key that is then used to encrypt the individual frames in t= he stream. Again tho, this is very preliminary and there are many details t= o work out. At this step, I largely just wanted to make sure people were aw= are of the draft as the discussion moves forward.
=C2=A0
The other thing that's missing, but should probably be in a separa= te document (that I think we're not ready to start yet) is a specificat= ion of client behavior, meaning when should the client use the same session= id (or "key id") for different requests. For example, if I have gmail open in one browser tab, and in another tab I= have a site, where teh HTML says "<img src=3D"mail.google.com= /imgs/yellow_arrow.gif">", should the request to mail.google.com us= e the same key id that I am using with GMail? =C2=A0The one that is bound t= o my identity? With the current cookie mechanism, the answer is yes. If we = define a new session mechanism, we can re-think this.


Agreed.

- James
=C2=A0
Yoav

On Jan 14, 2013, at 11:36 PM, James M Snell <jasnell@gmail.com> wrote:

Hello,

Just jumped over here from the ht= tp list per Yoav Nir's request for feedback with regards to the=C2=A0draft-williams-websec-session-co= ntinue-prob draft.=C2=A0

Overall I think the draft is a g= ood start. There definitely does need to be more of an explanation as to wh= y the existing cookie-based mechanism is bad.

As far as more forward looking f= eedback is concerned, I wanted to point to the In-Session Key Negotiation d= raft I wrote as input to the ongoing http/2 discussion


This draft introduces a new (cur= rently experimental) bidirectional key-negotiation sub-protocol within spdy= /http2 for the negotiation of secure keys and can be used for the establish= ment of authenticated and unauthenticated sessions.=C2=A0Running down through the list of requirements stated by the websec-session-continue-prob draft it covers= a good deal of the issues.

- James


--14dae934117b390c3104d355ed96-- From tav@espians.com Tue Jan 15 14:57:38 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D85D21F85D0 for ; Tue, 15 Jan 2013 14:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c22X8oYJZV7L for ; Tue, 15 Jan 2013 14:57:37 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id D84BF21F85CE for ; Tue, 15 Jan 2013 14:57:36 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id k10so1305058iea.1 for ; Tue, 15 Jan 2013 14:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=espians.com; s=google; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=wlF7GitUxjrmnYUoN2dnD6NfriLg3tkoyvTRNP7hnLk=; b=ZvrANKO83ILRoEIVxEZZd96dboZxqevR+GSmUFkHb4pah3Le3bditLjGgPcJxGKOVL MGXlxCmUgBMGRktOjhgN9Jo/lAGk2sdzg8gs6OBv6vImp9YpvQDoY4N0gJzfX2ue2wHX G4ehp8Yjiliu12r/N0983m7wtII1VphwuUJxU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=wlF7GitUxjrmnYUoN2dnD6NfriLg3tkoyvTRNP7hnLk=; b=fyFYa8J6CHGLI4T80wTP4GOrIQ0Kf6ageHESV4ULjxL14IIl2I+9T9L6WXiRDepCeE vzigsR40nrzt9bEuJtyQeBhMbNktR2d0Sk9Xoihm2rNVuOw9dpuMgOvZY4sbkVI+X7eq ATk4iEkLi8FlAkarF5YV3voLkaCHT4wO8fBsFGL/AdHTymeAkM58tp81XUHMASsvo7O2 JgzKzyVISNjfmz9mlkF7snVr8Ymvgws+s5bljZVxmIRjwm6z4l5AMhS8JKNiCscXUBs/ QoIAfcLnR/yrSQqAp0oZiMLbvN8vi6tZLICCJLPWxyh37Xw8HMabYfyiAfd4+PiLdEdP 98Tg== MIME-Version: 1.0 X-Received: by 10.50.212.3 with SMTP id ng3mr3098161igc.104.1358290656369; Tue, 15 Jan 2013 14:57:36 -0800 (PST) Received: by 10.64.46.130 with HTTP; Tue, 15 Jan 2013 14:57:36 -0800 (PST) Date: Tue, 15 Jan 2013 22:57:36 +0000 Message-ID: From: tav To: websec@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl4boqa/W8nq/750EDwxevYe0eSdu4L8eCQIsTiL05Ay67+0P11YB/90UTuwRn9N6x8luhA Subject: [websec] HSTS Hole Punching X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 22:58:17 -0000 Hi there, I realise that this proposal might be rather late in the process, but would it be possible to add a list of excluded subdomains in the STS header? My use case is that I am setting up a new service which has the STS header set so that users might have a more secure experience. However, for the purposes of sending referrer path information to non-HTTPS sites, I have one subdomain which does redirects over plain HTTP, e.g. http://from.espra.com/some/referrer/path. In an ideal world, I would be able to set a comprehensive STS header which excluded just that one subdomain, e.g. Strict-Transport-Security: max-age=31536000; includeSubDomains; exclude=from.espra.com And since having an exclude implicitly suggests includeSubdomains, it could be shortened to just: Strict-Transport-Security: max-age=31536000; exclude=from.espra.com There are, of course, alternative solutions, e.g. using another domain for the HTTP redirect or setting STS on individual subdomains without specifying includeSubdomains. But this seems like it would be a more elegant and secure solution. Thank you for your time! -- All the best, tav plex:espians/tav | tav@espians.com | +44 (0) 7809 569 369 http://tav.espians.com | http://twitter.com/tav | skype:tavespian From ynir@checkpoint.com Tue Jan 15 23:11:04 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150CA21F8839 for ; Tue, 15 Jan 2013 23:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryvSyIdabmQf for ; Tue, 15 Jan 2013 23:11:02 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 48BF421F882C for ; Tue, 15 Jan 2013 23:11:01 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r0G7Amjg006061; Wed, 16 Jan 2013 09:10:52 +0200 X-CheckPoint: {50F64FF7-1-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([fe80::80df:1c2c:3d29:3748%11]) with mapi id 14.02.0328.009; Wed, 16 Jan 2013 09:10:48 +0200 From: Yoav Nir To: tav Thread-Topic: [websec] HSTS Hole Punching Thread-Index: AQHN83PXECiDiGlZPEC12SVPh4OWp5hLZ8IA Date: Wed, 16 Jan 2013 07:10:47 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277211198598D@IL-EX10.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.157] Content-Type: text/plain; charset="us-ascii" Content-ID: <83BE1F81DBF0164A98C9437D71F9FAA6@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [websec] HSTS Hole Punching X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 07:11:04 -0000 Hi tav It's not just late in the process. The process is pretty much over. What yo= u are proposing could be either an extension to HSTS, or a revision to HSTS= . Furthermore, support of HSTS is not negotiated: the server just sends the h= eader, and the client either parses it or ignores it. There's no version ne= gotiation. So suppose your server sends the header that you propose, there = are three possible outcomes: 1. The client is old, and ignores HSTS 2. The client is current, registers HSTS, but ignores the exclusion 3. The client supports your extension. #1 and #3 are OK, but #2 (which is most of the desktop browsers in use toda= y), means that either from.espra.com will have STS applied (bad) or that no= ne of the subdomains will have STS (if you drop the includeSubDomains keywo= rd - somewhat bad) As a practical matter, this is one case where backwards compatibility will = cause you a lot of grief, unless you try to identify supporting implementat= ions by user agent string.=20 I guess the best thing would be to avoid the includeSubdomains keyword, and= just have an HSTS header for each of the servers except for from.espra.com Yoav On Jan 16, 2013, at 12:57 AM, tav wrote: > Hi there, >=20 > I realise that this proposal might be rather late in the process, but > would it be possible to add a list of excluded subdomains in the STS > header? >=20 > My use case is that I am setting up a new service which has the STS > header set so that users might have a more secure experience. However, > for the purposes of sending referrer path information to non-HTTPS > sites, I have one subdomain which does redirects over plain HTTP, e.g. > http://from.espra.com/some/referrer/path. >=20 > In an ideal world, I would be able to set a comprehensive STS header > which excluded just that one subdomain, e.g. >=20 > Strict-Transport-Security: max-age=3D31536000; includeSubDomains; > exclude=3Dfrom.espra.com >=20 > And since having an exclude implicitly suggests includeSubdomains, it > could be shortened to just: >=20 > Strict-Transport-Security: max-age=3D31536000; exclude=3Dfrom.espra.com >=20 > There are, of course, alternative solutions, e.g. using another domain > for the HTTP redirect or setting STS on individual subdomains without > specifying includeSubdomains. But this seems like it would be a more > elegant and secure solution. >=20 > Thank you for your time! >=20 > --=20 > All the best, tav >=20 > plex:espians/tav | tav@espians.com | +44 (0) 7809 569 369 > http://tav.espians.com | http://twitter.com/tav | skype:tavespian > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 > Email secured by Check Point From nico@cryptonector.com Thu Jan 17 08:18:19 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9058721F8686 for ; Thu, 17 Jan 2013 08:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.823 X-Spam-Level: X-Spam-Status: No, score=-3.823 tagged_above=-999 required=5 tests=[AWL=-1.846, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn+Bs42AIiaH for ; Thu, 17 Jan 2013 08:18:18 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id CC5E821F8667 for ; Thu, 17 Jan 2013 08:18:18 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 14EE367C072 for ; Thu, 17 Jan 2013 08:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=W9YOD6EhDF22i8jbmGT9Wp6 MOZ0=; b=mH7yrAHa1f7PQILc8yBu/opsTbjTM9QfpWeLbKRpw7cE8pSH6/GJst/ h1BmcgLIgSM1trm0gBpmNRvMIoZx0b6dP6mtbRGxcJqiL015oKNCyr8PGXaiU4lc JKS7FpJ3gcpwOnx16JEgJR/WipUF7owqMc2yQ9DtWUYlzAwciZ2o= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id BBC6867C06B for ; Thu, 17 Jan 2013 08:18:17 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so1676323wgb.25 for ; Thu, 17 Jan 2013 08:18:16 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.99.227 with SMTP id et3mr9209586wib.6.1358439496562; Thu, 17 Jan 2013 08:18:16 -0800 (PST) Received: by 10.217.82.73 with HTTP; Thu, 17 Jan 2013 08:18:16 -0800 (PST) In-Reply-To: <4613980CFC78314ABFD7F85CC302772111986E9B@IL-EX10.ad.checkpoint.com> References: <4613980CFC78314ABFD7F85CC302772111983941@IL-EX10.ad.checkpoint.com> <4613980CFC78314ABFD7F85CC302772111986E9B@IL-EX10.ad.checkpoint.com> Date: Thu, 17 Jan 2013 10:18:16 -0600 Message-ID: From: Nico Williams To: websec@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [websec] Forwarded review of draft-williams-websec-session-continue-prob-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:18:19 -0000 On Mon, Jan 14, 2013 at 17:05, Yoav Nir wrote: > I've shown this draft to a co-worker of mine (not on this list), and asked for a review. Here's some comments: > > - Overall, this is an interesting problem. There's been quite a few proposals now to solve it all before we identified this as worth treating as a problem separate from others: - draft-hammer-oauth-v2-mac-token - draft-hallambaker-httpintegrity - draft-williams-http-rest-auth - and several others There's also been a number of recent mentions of this in the context of CRIME in the HTTPbis WG list. > - The document is missing a list of deficiencies with using Cookies Well, for me CRIME is enough :) But sure, I'll flesh that out a bit. FWIW, I was under a hard deadline when i submitted the -00. > - Section 2.1 says that TLS protects against replay. Really? How? It doesn't have a protected counter like IPsec. If you try to replay a handshake it won't work: the server will almost certainly pick different nonces and, if relevant, DH keys, so the Finished message exchange will fail. If you try to replay a TLS record layer message... TLS will detect that too because of its use of sequence numbers. See RFC5246, search for "sequence"; see section 6.2.3 in particular. Search also for "replay". This is also true of DTLS. If you can neither replay handshakes, entire connections, nor individual records then it's got replay protection :) > - Will the resulting protocol support a transition from authenticated session to authenticated session for purposes such as re-authenticating after a specified time, or moving from weak authentication to strong authentication for high-value transactions. If we can make that work securely, then yes. > Nit: HTTP is HyperText **Transfer** Protocol, not **Transport*. This one is already fixed in Nico's repository. There were some instances of one and some of the other. It was just me being sloppy as I hurried to meet a hard deadline. Thanks! Nico -- From ynir@checkpoint.com Thu Jan 17 22:18:46 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B2921F888B for ; Thu, 17 Jan 2013 22:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.51 X-Spam-Level: X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOLqqgaZK5N0 for ; Thu, 17 Jan 2013 22:18:45 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8F36721F8888 for ; Thu, 17 Jan 2013 22:18:44 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r0I6Icj4016784; Fri, 18 Jan 2013 08:18:39 +0200 X-CheckPoint: {50F8E6A1-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([fe80::80df:1c2c:3d29:3748%11]) with mapi id 14.02.0328.009; Fri, 18 Jan 2013 08:18:38 +0200 From: Yoav Nir To: Nico Williams Thread-Topic: [websec] Forwarded review of draft-williams-websec-session-continue-prob-00 Thread-Index: AQHN9M5PbT3V1iRo0E6FSyqDNFm8H5hOfCgA Date: Fri, 18 Jan 2013 06:18:38 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772111988931@IL-EX10.ad.checkpoint.com> References: <4613980CFC78314ABFD7F85CC302772111983941@IL-EX10.ad.checkpoint.com> <4613980CFC78314ABFD7F85CC302772111986E9B@IL-EX10.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <7155D6AB4564964A8A954423AD05DD56@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [websec] Forwarded review of draft-williams-websec-session-continue-prob-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 06:18:46 -0000 On Jan 17, 2013, at 6:18 PM, Nico Williams wrote: > On Mon, Jan 14, 2013 at 17:05, Yoav Nir wrote: >> I've shown this draft to a co-worker of mine (not on this list), and ask= ed for a review. Here's some comments: >>=20 >> - Overall, this is an interesting problem. >=20 > There's been quite a few proposals now to solve it all before we > identified this as worth treating as a problem separate from others: >=20 > - draft-hammer-oauth-v2-mac-token > - draft-hallambaker-httpintegrity > - draft-williams-http-rest-auth > - and several others Yes, but those are not all solving the same issue. Some are for user authen= tication while others are for per-request MAC. You might be able to delegat= e either or both of these functions to the TLS layer (if present), so there= 's a lot of variation here. > There's also been a number of recent mentions of this in the context > of CRIME in the HTTPbis WG list. >=20 >> - The document is missing a list of deficiencies with using Cookies >=20 > Well, for me CRIME is enough :) But sure, I'll flesh that out a bit. > FWIW, I was under a hard deadline when i submitted the -00. OK. Next deadline is 25-Feb. >> - Section 2.1 says that TLS protects against replay. Really? How? It do= esn't have a protected counter like IPsec. >=20 > If you try to replay a handshake it won't work: the server will almost > certainly pick different nonces and, if relevant, DH keys, so the > Finished message exchange will fail. >=20 > If you try to replay a TLS record layer message... TLS will detect > that too because of its use of sequence numbers. See RFC5246, search > for "sequence"; see section 6.2.3 in particular. Search also for > "replay". This is also true of DTLS. >=20 > If you can neither replay handshakes, entire connections, nor > individual records then it's got replay protection :) You're right. I forgot about the seq_num field. >> - Will the resulting protocol support a transition from authenticated se= ssion to authenticated session for purposes such as re-authenticating after= a specified time, or moving from weak authentication to strong authenticat= ion for high-value transactions. >=20 > If we can make that work securely, then yes. I think it can be done. You can have a key for the unauthenticated session,= that's either secure (D-H or TLS extractor without a MitM) or insecure (se= rver assigns a key). Then you can mix in the key with the calculation of th= e key to the authenticated session. In the insecure case, an attacker could= authenticate and continue someone else's session, but they can only do it = once, since calculating a new key would invalidate the old key. So someone = could hijack your amazon.com shopping cart right before the checkout. Come = to think of it, this attack could be mounted physically at a supermarket, b= ut in either case, it's pretty low-value. >> Nit: HTTP is HyperText **Transfer** Protocol, not **Transport*. This on= e is already fixed in Nico's repository. >=20 > There were some instances of one and some of the other. It was just > me being sloppy as I hurried to meet a hard deadline. >=20 > Thanks! >=20 > Nico > -- > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 > Email secured by Check Point From julian.reschke@gmx.de Tue Jan 29 05:20:34 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C1821F87DF for ; Tue, 29 Jan 2013 05:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.384 X-Spam-Level: X-Spam-Status: No, score=-105.384 tagged_above=-999 required=5 tests=[AWL=-2.785, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFVc9p4SyTrd for ; Tue, 29 Jan 2013 05:20:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC0A21F87D1 for ; Tue, 29 Jan 2013 05:20:33 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MY1FO-1UUxXM37A0-00UqNv for ; Tue, 29 Jan 2013 14:20:32 +0100 Received: (qmail invoked by alias); 29 Jan 2013 13:20:32 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp010) with SMTP; 29 Jan 2013 14:20:32 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/tnblG/1Ttlc0FloEdNNPHWuUg0/vUmjMGHE8qr5 y3SuyluuTNe+do Message-ID: <5107CCA1.2070002@gmx.de> Date: Tue, 29 Jan 2013 14:20:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: IETF WebSec WG References: <50994817.1030503@gmx.de> In-Reply-To: <50994817.1030503@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [websec] WGLC feedback for X-Frame-Options X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 13:20:34 -0000 On 2012-11-06 18:25, Julian Reschke wrote: > Hi there, > > here's my feedback from the HTTP/editorial point of view: > ... Just checking: is the WG still working on this draft? There doesn't seem to be any activity since October 2012... Best regards, Julian From ynir@checkpoint.com Tue Jan 29 05:30:15 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD9D21F8890 for ; Tue, 29 Jan 2013 05:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNiwygfQwiXT for ; Tue, 29 Jan 2013 05:30:15 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C2A9321F87D7 for ; Tue, 29 Jan 2013 05:30:14 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r0TDU4gr009586; Tue, 29 Jan 2013 15:30:04 +0200 X-CheckPoint: {5107CB99-1-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([169.254.3.103]) with mapi id 14.02.0328.009; Tue, 29 Jan 2013 15:30:04 +0200 From: Yoav Nir To: Julian Reschke Thread-Topic: [websec] WGLC feedback for X-Frame-Options Thread-Index: Ac28Q8fEpL3h0k0fQo+0+fl3Ysmd9BBzt9WAAABUV4A= Date: Tue, 29 Jan 2013 13:30:03 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772111994B49@IL-EX10.ad.checkpoint.com> References: <50994817.1030503@gmx.de> <5107CCA1.2070002@gmx.de> In-Reply-To: <5107CCA1.2070002@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <6E750DDA8F869C4AACF2F8681B236F6C@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] WGLC feedback for X-Frame-Options X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 13:30:15 -0000 Yes. Tobias will submit a revised version soon, incorporating the WGLC comm= ents. Yoav On Jan 29, 2013, at 3:20 PM, Julian Reschke wrote: > On 2012-11-06 18:25, Julian Reschke wrote: >> Hi there, >>=20 >> here's my feedback from the HTTP/editorial point of view: >> ... >=20 > Just checking: is the WG still working on this draft? There doesn't seem = to be any activity since October 2012... >=20