Re: [TLS] TLS Proxy Server Extension

David McGrew <mcgrew@cisco.com> Wed, 03 August 2011 21:36 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84A21F8581 for <tls@ietfa.amsl.com>; Wed, 3 Aug 2011 14:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.71
X-Spam-Level:
X-Spam-Status: No, score=-102.71 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 n-+RtE3OUbrj for <tls@ietfa.amsl.com>; Wed, 3 Aug 2011 14:36:17 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEAD21F857D for <tls@ietf.org>; Wed, 3 Aug 2011 14:36:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2995; q=dns/txt; s=iport; t=1312407390; x=1313616990; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=jN2QXy8gXDdvJ4QfQbxlYgqcKGG8YMr1tzJjTZ8WMqI=; b=YFxSvZFtiinURxnPOjaipKlWE/IIyS3XRVahNx++9AtXqprSURJKanIW cm9uPAZFa2Yjp1/QVBLhuSVEm8iQgNvv0NGP+cdNTKCMNURqx3ADvLpKH L5La7crJVOZ/16xLN4E/3HZlT6Ej+FyuQaE8o8zFOxtvWve/TOxifzQUN Y=;
X-IronPort-AV: E=Sophos;i="4.67,312,1309737600"; d="scan'208";a="9421431"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 03 Aug 2011 21:36:30 +0000
Received: from stealth-10-32-254-211.cisco.com (stealth-10-32-254-211.cisco.com [10.32.254.211]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p73LaSWS002092; Wed, 3 Aug 2011 21:36:29 GMT
Message-Id: <F9944E17-65C1-4B64-92C3-93D2BC85D8C5@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: "Kemp, David P." <DPKemp@missi.ncsc.mil>
In-Reply-To: <C1A47F1540DF3246A8D30C853C05D0DA03DE24AC@DABECK.missi.ncsc.mil>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 3 Aug 2011 14:36:27 -0700
References: <201108011615.p71GFGMT019612@fs4113.wdf.sap.corp> <2A88269D-38AF-4695-8DD0-0543C2391423@cisco.com> <C1A47F1540DF3246A8D30C853C05D0DA03DE24AC@DABECK.missi.ncsc.mil>
X-Mailer: Apple Mail (2.936)
Cc: tls@ietf.org
Subject: Re: [TLS] TLS Proxy Server Extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2011 21:36:18 -0000

On Aug 3, 2011, at 1:55 PM, Kemp, David P. wrote:

>
>
>
> From: David McGrew
>> On Aug 1, 2011, at 9:15 AM, Martin Rex wrote:
>>> If the proxy terminates the clients
>>> TLS connection and establishes a new connection to the real server,
>>> then it will have to impersonate the real server to the client
>>
>> No, that's not right, at least not if "impersonate" is meant in the
>> cryptographic sense.   If "impersonate" is meant in the sense that a
>> proxy can modify the traffic passing through it, then yes, that is a
>> goal for the system; it is a requirement if TLS is to be used to
>> protect communications when an HTTP proxy is present (for many types
>> of proxies).
>
> A TLS connection between S and C provides integrity protection  
> (which by
> definition is impossible without authentication): C knows that data it
> receives is identical to that sent by S.
>
> How do you propose to define roles that extend integrity properties  
> to a
> three-party protocol?  C must know that data it receives from S is  
> sent
> by S, with no insertions or deletions.  And that data it receives  
> from P
> was sent by P with no insertions or deletions.  "Modifying" traffic is
> fundamentally incompatible with data integrity - the concept is
> meaningless.  There must be either two independent unmodifiable data
> streams between C and S and between C and P, or there must be a single
> stream between C and P, where C trusts P to be the data provider  
> without
> knowing or caring where P got the data in the first place.  That is  
> what
> is meant by impersonation.
>
> In an application protocol it would be appropriate to tag sections of
> data that have different properties and originated from different
> sources - think chat room, or a portion-marked word document.  TLS
> claims to protect an application-independent data stream - I have no
> idea how you define semantics of a 3-party "session" without becoming
> application-specific.
>
> Dave


The idea of authentication in which two or more parties are trusted to  
create authentication tags or signatures occurs in both crypto theory  
(group signatures and threshold signatures, for instance) and crypto  
standards (such as group authentication as defined in RFC 3740 and  
used in RFC 5374).  Security models in which one party can modify data  
created by another can be sound and consistent, but of course we need  
to be careful about definitions, as you are pointing out.  (As an  
extreme example, data aggregation in sensor networks allow many  
different senders to affect a single piece of data.)

It would be most correct to describe the goals of the draft as  
establishing a pair of confidential and authenticated data streams  
between C/P and P/S, while having a three-party entitiy  
authentication.   I think a good way to describe the goal would be:  
multiparty entity authentication with pairwise key establishment.

David