Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04

Alan DeKok <aland@deployingradius.com> Mon, 08 April 2013 13:28 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06AA21F93DA for <radext@ietfa.amsl.com>; Mon, 8 Apr 2013 06:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQdXQwcjGrLc for <radext@ietfa.amsl.com>; Mon, 8 Apr 2013 06:28:10 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6057821F9157 for <radext@ietf.org>; Mon, 8 Apr 2013 06:28:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 0AD2B22410BC; Mon, 8 Apr 2013 15:28:10 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaQWtzmfqS4k; Mon, 8 Apr 2013 15:28:09 +0200 (CEST)
Received: from Thor-2.local (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id E5CF32240860; Mon, 8 Apr 2013 15:28:08 +0200 (CEST)
Message-ID: <5162C5E7.2050004@deployingradius.com>
Date: Mon, 08 Apr 2013 09:28:07 -0400
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <peterd@iea-software.com>
References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <alpine.WNT.2.00.1304021450180.3988@SMURF> <515C3604.3040406@deployingradius.com> <alpine.WNT.2.00.1304042021411.3988@SMURF> <tslli8xnoms.fsf@mit.edu> <515ED047.3040200@deployingradius.com> <alpine.WNT.2.00.1304051020120.3988@SMURF> <5160255B.40409@deployingradius.com> <alpine.WNT.2.00.1304060913320.3988@SMURF> <5160B785.8070703@deployingradius.com> <alpine.WNT.2.00.1304071946370.1952@littlesmurf>
In-Reply-To: <alpine.WNT.2.00.1304071946370.1952@littlesmurf>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Sam Hartman <hartmans@painless-security.com>, "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 13:28:11 -0000

Peter Deacon wrote:
> On Sat, 6 Apr 2013, Alan DeKok wrote:
> 
>> Peter Deacon wrote:
>>> Requests from unknown IPs by itself is not useful.  Normally access to
>>> the RADIUS request (NAS-ID) often provides relevant clue.
> 
>>  That's not part of standard RADIUS.  If you have a proprietary
>> extension, you're responsible for ensuring it works.  The IETF isn't.
> 
> What "proprietary extension" is required to log incoming requests?

  So... your best option is to lie about what I said?

> Lets examine the complete matrix of options for RADIUS/UDP vs
> RADIUS/DTLS clients and servers.

  Let's not.  Conversations presume that both parties operate in good faith.

> With regards to the security review claim the migration concept is
> susceptible to trivial MITM in the network path simply by filtering out
> the more secure (DTLS) messages.  Whether it is the client that does it
> or the server makes no difference.  This scheme is insecure either way.

  Nonsense.

> The problem is servers would not have the option of turning off the
> automatic migration behavior.

  You've understood that, at least.

>  Side effect of this is that multiple clients behind a single IP 

  ... is not part of RADIUS.

  Once again, you're ignoring my messages about that topic.  You seem to
think that by simply repeating yourself ad nauseum, you can win a
logical argument.  Logic doesn't work that way.

  IMHO, hell will freeze over before RADIUS/UDP standardizes multiple
clients behind one IP.

  Alan DeKok.