Re: [proxies] Call for comments and co-authors: <draft-hoeper-proxythreat-00.txt>

Stefan Winter <stefan.winter@restena.lu> Thu, 16 October 2008 13:43 UTC

Return-Path: <proxies-bounces@ietf.org>
X-Original-To: proxies-archive@ietf.org
Delivered-To: ietfarch-proxies-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE8A3A698E; Thu, 16 Oct 2008 06:43:15 -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 830553A698E for <proxies@core3.amsl.com>; Thu, 16 Oct 2008 06:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.231
X-Spam-Level:
X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599]
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 MYGWIkD520FO for <proxies@core3.amsl.com>; Thu, 16 Oct 2008 06:43:13 -0700 (PDT)
Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 8BCE73A6805 for <proxies@ietf.org>; Thu, 16 Oct 2008 06:43:13 -0700 (PDT)
Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 5B16192683; Thu, 16 Oct 2008 15:44:14 +0200 (CEST)
Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 48AFAB8B3D; Thu, 16 Oct 2008 15:44:14 +0200 (CEST)
Message-ID: <48F7452E.8040006@restena.lu>
Date: Thu, 16 Oct 2008 15:44:14 +0200
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: Katrin Hoeper <katrin.hoeper@nist.gov>
References: <7.0.1.0.2.20081014111653.0251b108@nist.gov>
In-Reply-To: <7.0.1.0.2.20081014111653.0251b108@nist.gov>
X-Enigmail-Version: 0.95.7
X-Virus-Scanned: ClamAV
Cc: proxies@ietf.org
Subject: Re: [proxies] Call for comments and co-authors: <draft-hoeper-proxythreat-00.txt>
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-Archive: <https://www.ietf.org/mailman/private/proxies>
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: proxies-bounces@ietf.org
Errors-To: proxies-bounces@ietf.org

Hi Katrin,

> I have put together a 00-draft attempting to summarize the discussions
> in Philadelphia and on this list.

Thanks a lot!

> Please read the draft and send me your comments:

Attacks 1-4 are really quite broad in scope. They work on the network
layer and can be applied to all sorts of packets. While what's written
in these sections is true, I wonder if it needs an explicit mention in
this document, which is supposed to deal with AAA proxy-specific attacks.

Attack 5 is more severe than stated in the document: AAA protocols might
send their payload in parts in the clear. Intermediate hops (not only
AAA proxies) may extract information out of these payloads, even without
knowledge of keying material. RADIUS only encrypts a small subset of
attributes on the wire. Diameter communication MUST be encrypted with
IPSec or TLS (but there was talk going on on the dime list for making
this a SHOULD in 3588bis, IIRC).

5.2.2 re "[Editor's note: Is this true?]": Access-Request packets in
RADIUS can be unauthenticated and thus be replayed. This will happen if
the Message-Authenticator digest is not present in the request. This is
NOT RECOMMENDED as per RFC5080, but possible (and existing deployed
practice).

5.2.8, re "[Editor's note: Are AAA attributes typically protected?]":
There are key wrapping schemes that provide encryption between the ends
of the AAA communication for individual attributes. They require
out-of-band signalling of the wrapping keying material though, and are
not an inherent protocol feature. So while they can be protected it is
"typically" not the case (at least in the networks I work with, maybe
other people have other experiences).

Oh, and a typo in section 6:

This section uses the thread model 

-> threat


Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

_______________________________________________
Proxies mailing list
Proxies@ietf.org
https://www.ietf.org/mailman/listinfo/proxies