Re: [proxies] Recap for -00 draft

Bernard Aboba <bernard_aboba@hotmail.com> Fri, 02 May 2008 22:30 UTC

Return-Path: <proxies-bounces@ietf.org>
X-Original-To: proxies-archive@ietf.org
Delivered-To: ietfarch-proxies-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60D063A6CD0; Fri, 2 May 2008 15:30:11 -0700 (PDT)
X-Original-To: proxies@core3.amsl.com
Delivered-To: proxies@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589ED3A6A65 for <proxies@core3.amsl.com>; Fri, 2 May 2008 15:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.572
X-Spam-Level:
X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6wHc-OTvcyH for <proxies@core3.amsl.com>; Fri, 2 May 2008 15:30:04 -0700 (PDT)
Received: from blu139-omc2-s24.blu139.hotmail.com (blu139-omc2-s24.blu139.hotmail.com [65.55.175.194]) by core3.amsl.com (Postfix) with ESMTP id 100173A6913 for <proxies@ietf.org>; Fri, 2 May 2008 15:30:03 -0700 (PDT)
Received: from BLU137-W12 ([65.55.162.184]) by blu139-omc2-s24.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 May 2008 15:30:05 -0700
Message-ID: <BLU137-W121A8FA1FB39EFCD24114593DA0@phx.gbl>
X-Originating-IP: [131.107.0.105]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Katrin Hoeper <katrin.hoeper@nist.gov>, <proxies@ietf.org>
Date: Fri, 2 May 2008 15:30:06 -0700
Importance: Normal
In-Reply-To: <7.0.1.0.2.20080502100208.023e9f60@nist.gov>
References: <7.0.1.0.2.20080502100208.023e9f60@nist.gov>
MIME-Version: 1.0
X-OriginalArrivalTime: 02 May 2008 22:30:05.0661 (UTC) FILETIME=[11FF30D0:01C8ACA4]
Subject: Re: [proxies] Recap for -00 draft
X-BeenThere: proxies@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for ad hoc group interested in security and proxies <proxies.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/proxies>, <mailto:proxies-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:proxies@ietf.org>
List-Help: <mailto:proxies-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/proxies>, <mailto:proxies-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0013148254=="
Sender: proxies-bounces@ietf.org
Errors-To: proxies-bounces@ietf.org

Comments below. 




Date: Fri, 2 May 2008 10:07:22 -0400To: proxies@ietf.orgFrom: katrin.hoeper@nist.govSubject: [proxies] Recap for -00 draftHi, it’s good to see that we already had some good discussions on this list.I would like to briefly recap and outline next steps for a first draft. So far we seem to have collected: I. USE CASE1) a worldwide WLAN that enables roaming registered users to access information free of charge(thanks Stefan for your detailed description) II. THREATS:1) proxies can listen to traffic2) insert fake accounting  packets

[BA] It's worthwhile to point out that authentication data may not necessarily take the same path as accounting data.   So an authentication proxy need not necessarily also function as an accounting proxy -- particularly if we are talking about a roaming network in which there is no settlement. 
 III. FEASIBILIY -easy to sniff traffic for proxies-most attributes readable due to AAA hop-by-hop security 
 
[BA] I'd note that Diameter (RFC 3588) distinguishes between types of AAA agents.  In addition to proxies, there are also Re-directs.  This enables the separation of the functions of proxies (described in RFC 2607) to some extent.  For example, an Agent that functions solely as a "route server" can be configured as a Re-direct, without actually needing to gain access to attributes flowing between the Diameter client and server.    IV. SEVERITY-depends on the content of the exchanged dataWhen data contains valuable user information (such as the user’s age), this information can be correlated with the user identity and then be exploited.-depends on national laws and regulations-depends on whether offered services are free or paid  -some providers seem to be more worried about malicious insiders and outsider sniffers rather than proxies V. SOLUTIONSThere have been some proposals but I’d like to keep this discussion for later on, after we decided if and how we should continue. (see my previous post)  NEXT STEPS & CALL FOR COMMENTSI will now go ahead and put together a -00 draft about items I-IV using our Philadelphia discussion, ppt slides, and the discussion on this list as input. Please send other information that you would like to be included in the 00 draft to the list. Also let me know if you disagree with previous discussions (items I-IV, not solutions!). Off course, everybody is more than welcome to volunteer as a co-author. Just let me know. We definitely need more use cases. I will try to cover all aspects listed under IV. Severity in the use cases. It would be very helpful if people could send me more “real implementation” examples of networks using proxies, especially the architecture of such networks and the particular functions of proxies in them (e.g. what data do they need to know).  Katrin


Katrin HoeperComputer Security DivisionNational Institute of Standards and Technology (NIST)100 Bureau Dr. Mail stop: 8930Gaithersburg, MD 20899(301) 975 - 4024
_______________________________________________
Proxies mailing list
Proxies@ietf.org
https://www.ietf.org/mailman/listinfo/proxies