Re: [secdir] Secdir review of draft-ietf-radext-dynamic-discovery-12

Jouni Korhonen <jouni.nospam@gmail.com> Mon, 05 January 2015 03:29 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF5B1A1A2D; Sun, 4 Jan 2015 19:29:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYVjNrAQEyPv; Sun, 4 Jan 2015 19:29:10 -0800 (PST)
Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BB81A1A33; Sun, 4 Jan 2015 19:29:10 -0800 (PST)
Received: by mail-pd0-f180.google.com with SMTP id fl12so11681975pdb.39; Sun, 04 Jan 2015 19:29:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8/avYNjhpQuOrDNdQk463TwD/gJrjx3I/2h5Cme7U0Q=; b=OvZKlvGuyqvwI2yigb9HafMpdoB6/szcC7xe5a1ZgdRLR09fk29Qr44XnyX+yxjcFW BMb5pfFHvAgads8VKRPeXLh0KO25cngNLtxYsB0L24cf3ZdjOb4OID4j7VDTZVPZfs1B /V84p4QXX1+Xb2kiLU/MkX3Ux6zmnhbxL5+f8UAKhVw2owTjWHf/3TqMicLKbXpPzO+n WpmML+tuxnW2duVtXl+8IUhJsu8pMOVPtkfW0w4JxmovSP6oTFtagoqhGcpotThUJmzg UVOKUMgeAufQJXKxDV4JZHLzhEHBb6TlLLMNldftFGILTPCnwCXFix/ea/h9pzZXrt1m FWvQ==
X-Received: by 10.68.231.71 with SMTP id te7mr57828500pbc.38.1420428549482; Sun, 04 Jan 2015 19:29:09 -0800 (PST)
Received: from ?IPv6:2601:9:3400:6c:4d19:ed9d:99ba:fad9? ([2601:9:3400:6c:4d19:ed9d:99ba:fad9]) by mx.google.com with ESMTPSA id th7sm53168899pac.47.2015.01.04.19.29.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jan 2015 19:29:08 -0800 (PST)
Message-ID: <54AA04FA.1040406@gmail.com>
Date: Sun, 04 Jan 2015 19:28:58 -0800
From: Jouni Korhonen <jouni.nospam@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Brian Weis <bew@cisco.com>, The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-radext-dynamic-discovery.all@tools.ietf.org
References: <D5A0C8AD-1194-4A95-BA7D-B87542F8B82D@cisco.com>
In-Reply-To: <D5A0C8AD-1194-4A95-BA7D-B87542F8B82D@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LKP4islBILJOiJl7iac9EAMo9iY
Subject: Re: [secdir] Secdir review of draft-ietf-radext-dynamic-discovery-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jan 2015 03:29:13 -0000

Thanks you for the detailed review Brian. We'll have a look and come 
back to these shortly.

- Jouni

12/24/2014, 1:05 PM, Brian Weis kirjoitti:
> I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.
>
> This document specifies a means to find authoritative RADIUS servers for a given realm. This can be useful when authenticating/authorizing devices within a roaming consortium (e.g., eduroam). An authoritative RADIUS client trying to authenticate/authorize a host or perform accounting for that host finds a RADIUS server by querying DNS for service records defined in this document. Once a candidate sever has been found in DNS, the querier initiates a RADIUS protocol to it protected by TLS, authorizes it based on information in its certificate, and then RADIUS happens in the usual fashion. The document is almost ready for publication, in my opinion.
>
> There’s not much background given, and having an overview of the solution architecture in the Introduction would be useful. I.e., a description and picture showing the actors and the communication flows between them.  I don’t have complete confidence that I correctly understood which actors are involved in the RASIUS/TLS transaction -- in some sections it seems that RADIUS clients are initiating requests and sometimes RADIUS servers and I thought only clients contacted servers. An overview of the actors would probably have clarified that.
>
> If I understand correctly how roaming consortiums currently work today, a RADIUS client within a consortium needing to make a AAA call to a RADIUS server in another realm does not contact the server directly. Instead, it routes the request through a hierarchy of RADIUS servers following roots of trust. The trust model in this document seems to be bypass the roots of trust, where the client directly contacts the server. This seems to be discussed in the Section 6 (Privacy Considerations) discussion of “clearinghouses", but if the trust model is changed, this is a bigger impact than privacy so ought to be discussed explicitly someplace in the document.
>
> Section 2.1.1.3 discusses the use of TLS cipher suites, and makes the point that certificate based cipher suites need to be used because there won’t be any pre-distributed secret key material available. That’s good advice. I think the section should also give advice on choosing trust roots. This is important because the identity of the server was gotten in an untrusted manner (from unsecured DNS), and the certificate it presents contains information used for  authorization of a server (i.e., SubjectAltName). If a RADIUS client were to accept a certificate signed by a wide range of trust roots (e.g, the set of roots used by browsers, where the trustability of many CAs in the hierarchy is unknown) then the RADIUS client would be  ill advised to trust authorization information claims in the hierarchy. On the other hand, if the trust roots were restricted to a set of highly trusted trust roots maintained by the consortium, then the authorization information in the certificate would be
 trustable. This should be explained.
>
> Section 2.2 defines the NAIRealm name as a form of otherName. This makes sense. But there is also a paragraph discussing sRVName, which is confusing. I think it’s clarifying who sRVName isn’t applicable; it would be good state that plainly at the beginning of the paragraph.
>
> Section 5  (first paragraph) makes the point that the information gotten from DNS can’t be trusted. But I would suggest a slight rewording: s/can not be trusted/is not sufficient to identify an authorized server/.
>
> Brian
>