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

Sam Hartman <hartmans@painless-security.com> Mon, 08 April 2013 19:11 UTC

Return-Path: <hartmans@painless-security.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 93E0521F8EE1 for <radext@ietfa.amsl.com>; Mon, 8 Apr 2013 12:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
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 QYDXbwLxovsE for <radext@ietfa.amsl.com>; Mon, 8 Apr 2013 12:11:19 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id CAA8021F89C3 for <radext@ietf.org>; Mon, 8 Apr 2013 12:11:19 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id D4C3320556; Mon, 8 Apr 2013 15:09:55 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0FB674499; Mon, 8 Apr 2013 15:11:17 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: Arran Cudbard-Bell <a.cudbardb@networkradius.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> <tslppy5i2dm.fsf@mit.edu> <5162C651.2000200@deployingradius.com> <alpine.WNT.2.00.1304080801440.1952@littlesmurf> <tslppy5ghnf.fsf@mit.edu> <5162F9BA.7030500@deployingradius.com> <tsltxnhey5u.fsf@mit.edu> <0FFFD8DE-5337-4A4F-A844-F8F05297A25E@freeradius.org> <tslk3odexnp.fsf@mit.edu> <D2A88F51-F694-49E7-BB5C-30814A70208A@networkradius.com>
Date: Mon, 08 Apr 2013 15:11:16 -0400
In-Reply-To: <D2A88F51-F694-49E7-BB5C-30814A70208A@networkradius.com> (Arran Cudbard-Bell's message of "Mon, 8 Apr 2013 14:50:08 -0400")
Message-ID: <tsly5cset2j.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: radext@ietf.org, Alan DeKok <aland@deployingradius.com>
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 19:11:22 -0000

>What having a dedicated DTLS port gets you, is the ability to mandate that between network boundaries only encrypted RADIUS traffic may pass. This would otherwise be difficult to enforce without DPI. 

True.
no objection to dedicated dtls port.


>As an aside, were still working under the assumption that it's non-trivial to recover the shared secret from unecrypted RADIUS packets, correct?

I don't know.  Enumerating through I think 96^11 md4s is apparently
trivial given reasonably-priced hardware for cracking.  So probably $10k
investment.  See recent discussions of hash cracking on GPUs.  However,
md5 is a bit slower, and 11 is less than 16.  I think I'd say that I
would be unsurprised if someone broke RADIUS secrets entirely, and would
be entirely unsurprised if brute forcing the secrets anyone is actually
using in practice was easy.
On the other hand I would not commit to being able to brute force a
particular RADIUS secret without more research.