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

"Brian Weis (bew)" <bew@cisco.com> Tue, 03 February 2015 17:44 UTC

Return-Path: <bew@cisco.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 F21A81A6FE6; Tue, 3 Feb 2015 09:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.312
X-Spam-Level:
X-Spam-Status: No, score=-10.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 1IClxeQTBGYk; Tue, 3 Feb 2015 09:44:29 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F3F1A1BFF; Tue, 3 Feb 2015 09:43:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5924; q=dns/txt; s=iport; t=1422985405; x=1424195005; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ieu/EZ/Lfus6b0cEFP3sUU54q6xzrCS0kzNgw2GluDg=; b=aIu7/XGfJipZOS8kSXW8TV7U4snpS2h2gMexl6+xfhGpAUzLb3cnpX1T 1OfW/zVwx4gPMkdcd292Ps+82ZykGTIbwMZMWsLiZCwqbIspeETzM7AvP o/vAnYVWt2yP0MWZe+OXdVAZ9F5iBzs3QpjFRN8IzGl0cR4QUOGAgTaH6 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BABQA/CNFU/4ENJK1RBgODBlJZBMUFhXECgR5DAQEBAQF9hAwBAQEDAXkFCwIBCBIGLjIXDgIEDgUbBIgGCA3XHAEBAQEBAQEBAQEBAQEBAQEBAQEBARePFgcDBwEdIxAHEYMFgRMFjwyDToVYgU2REiKBfYFxb4ECCRcifgEBAQ
X-IronPort-AV: E=Sophos;i="5.09,514,1418083200"; d="scan'208";a="120111059"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP; 03 Feb 2015 17:43:24 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t13HhO7W019083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 17:43:24 GMT
Received: from xmb-aln-x04.cisco.com ([169.254.9.248]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 11:43:24 -0600
From: "Brian Weis (bew)" <bew@cisco.com>
To: Alan DeKok <aland@deployingradius.com>
Thread-Topic: [secdir] Secdir review of draft-ietf-radext-dynamic-discovery-12
Thread-Index: AQHQP9jo/4E4W9eQfUWTlaJGLxs9hA==
Date: Tue, 3 Feb 2015 17:43:23 +0000
Message-ID: <2B42564B-1BC8-437D-AACD-69785A90A795@cisco.com>
References: <D5A0C8AD-1194-4A95-BA7D-B87542F8B82D@cisco.com> <A0A09939-39AF-4CFD-B358-E42D9D60BD0E@deployingradius.com>
In-Reply-To: <A0A09939-39AF-4CFD-B358-E42D9D60BD0E@deployingradius.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.32.244.211]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <009BCE590706FB448D94B05E2152CFD0@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/j6AV0zDDA5AywoxQ2za5cvHRwlk>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-radext-dynamic-discovery.all@tools.ietf.org" <draft-ietf-radext-dynamic-discovery.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
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: Tue, 03 Feb 2015 17:44:38 -0000

Hi Alan,

The clarification below was very useful.  Perhaps the authors will find it valuable to include the references you mentioned, and clarify that there is expected to be a limited number of trusted (preferably one) trusted to issue certificates for the consortium use case.

Thanks,
Brian

On Jan 4, 2015, at 8:48 PM, Alan DeKok <aland@deployingradius.com> wrote:

> On Dec 24, 2014, at 4:05 PM, Brian Weis <bew@cisco.com> wrote:
> 
>  I’m not the document author, but I can help give some clarification.
> 
>> 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.
> 
>  The current roaming behaviour is discussed in the NAI document, Section 3.  Unfortunately, it also assumes some familiarity with the field.
> 
> http://tools.ietf.org/html/draft-ietf-radext-nai-15#section-3
> 
>  Perhaps the simplest explanation is that RADIUS is client-server.  Clients request authentication on behalf of users, and servers authenticate the users.  The key thing is that historically, proxying has been static, and provisioning of proxy configuration has been entirely outside of the protocol.  i.e. proxies operate by consensus and habit, not by standard behaviour.
> 
>  A long description of the Eduroam consortium is available as an individual draft:
> 
> http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-04
> 
>  However, *commercial* proxies do not operate in the eduroam model.  Commercial proxies are largely “star” configurations.  An interconnect company sits at the centre of a star.  It may connect to one or more other interconnect providers.  Routes are largely static, and are usually updated by hand, after legal contracts have been exchanged.
> 
>  This document is standardizing provisioning of RADIUS proxying, via dynamic methods.
> 
>> 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.
> 
>  Clients are the only ones initiating requests.  In some cases, the system running RADIUS can behave as a client or as a server, depending on it’s needs.  That makes it more complicated.
> 
>> 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.
> 
>  s/does not/may not/
> 
>> Instead, it routes the request through a hierarchy of RADIUS servers following roots of trust.
> 
>  That’s how eduroam works.  Commercial proxies are configured differently.
> 
>  However, they both operate on a “fire and forget” model.  A RADIUS server which wants to proxy a request somehow (magically, almost) determines which upstream server to use.  The “magic” part of that process is what the dynamic discovery document is trying to standardize.
> 
>> 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.
> 
>  Current RADIUS practice uses a limited set of CAs.  Generally, only one.  This use-case is *very* different than that for browsers.  This document should make that clearer.  Shipping a RADIUS server (or client) with a list of pre-configured CAs is a *very bad* idea.  RFC 6614 (RADIUS over TLS) should probably have had such statements.  RFC 7360 (RADIUS over DTLS) has some related text which would be useful here:
> 
> https://tools.ietf.org/html/rfc7360
> 
>  Section 10.4: ...
> 
>   Therefore, clients SHOULD NOT be pre-configured with a list of known
>   public CAs by the vendor or manufacturer.  Instead, the clients
>   SHOULD start off with an empty CA list.  The addition of a CA SHOULD
>   be done only when manually configured by an administrator.
>   This scenario is the opposite of web browsers, where they are pre-
>   configured with many known CAs.  The goal there is security from
>   third-party observers, but also the ability to communicate with any
>   unknown site that presents a signed certificate.  In contrast, the
>   goal of RADIUS/DTLS is both security from third-party observers and
>   the ability to communicate with only a small set of well-known
>   servers.
> 
>> 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.
> 
>  Generally there’s only one root CA for a consortium.  I’m not sure what the use-case would be for multiple root CAs.
> 
>  Alan DeKok.
> 

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com