Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-radext-radsec-11
Stefan Winter <stefan.winter@restena.lu> Tue, 31 January 2012 07:41 UTC
Return-Path: <stefan.winter@restena.lu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7D821F85D6 for <gen-art@ietfa.amsl.com>; Mon, 30 Jan 2012 23:41:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.408
X-Spam-Level:
X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599]
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 5DpMsqaN8i96 for <gen-art@ietfa.amsl.com>; Mon, 30 Jan 2012 23:41:49 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA1621F84B5 for <gen-art@ietf.org>; Mon, 30 Jan 2012 23:41:48 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 662DB10590; Tue, 31 Jan 2012 08:41:46 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:91c1:6a7a:3f7f:a108] (unknown [IPv6:2001:a18:1:8:91c1:6a7a:3f7f:a108]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4C6B710581; Tue, 31 Jan 2012 08:41:46 +0100 (CET)
Message-ID: <4F279B35.9010409@restena.lu>
Date: Tue, 31 Jan 2012 08:41:41 +0100
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Pete McCann <mccap@petoni.org>
References: <CACvMsLGwVVF3x92O7j-eBjC4_PZ2EC_DuP-pgi1E-4-XkqT6SA@mail.gmail.com>
In-Reply-To: <CACvMsLGwVVF3x92O7j-eBjC4_PZ2EC_DuP-pgi1E-4-XkqT6SA@mail.gmail.com>
X-Enigmail-Version: 1.3.5
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig96886BF823DEE048A3C67F47"
X-Virus-Scanned: ClamAV
X-Mailman-Approved-At: Tue, 31 Jan 2012 05:09:47 -0800
Cc: draft-ietf-radext-radsec.all@tools.ietf.org, gen-art@ietf.org
Subject: Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-radext-radsec-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jan 2012 07:41:50 -0000
Hello, thanks for your review! > Minor issues: > > Section 2.4: > In TLS-X.509 with PKI infrastructure, a client is uniquely identified > by the serial number of the tuple (presented client > certificate;Issuer). > SHOULD BE: > In TLS-X.509 with PKI infrastructure, a client is uniquely identified > by the tuple (serial number of presented client certificate;Issuer). Right, thanks for spotting; fixed now in my working copy. > Because RADIUS supports the Disconnect Request (server-to-client) message, > it seems that there is some requirement to keep the TLS session open for the > duration of the access that was authorized. Otherwise, the server would not be > able to send such a packet to the client without initiating its own > TLS connection > which may not be possible or desirable. Is this aspect of the specification > inherited from the referenced TCP specification? It may be helpful to > add a paragraph > about this issue. Dynamic Authoirzation traffic is only very loosely coupled with the corresponding authentication traffic. In particular, RFC5176 states that a DynAuth Client (i.e. the one that would initiate the DM message) may or may not be co-located with the RADIUS server which handled the authentication. There's a recommendation that a DynAuth client should not send its traffic directly to the NAS and instead route it via the RADIUS server. If that recommendation is followed, it may make sense to re-use the same TLS session to send the packets indeed. But it is certainly not a *requirement* that these types of traffic are "bundled" together, or even just take the same path. It's true that there may be some operational hassle in setting up a TLS session in the reverse direction if the original TLS session doesn't exist any more. RADIUS/TLS shares this fate with all the other transports though (in RADIUS/UDP, getting in the reverse direction through a firewall, possibly combined with traversing NAT is "fun"; same goes for RADIUS/TCP). So, nothing "new" here IMHO. > Nits/editorial comments: > > Section 2.3: > x.y.z > Did you mean to fill in a real section number here? Right, for TLS 1.2 that would be RFC6066, section 6. I have updated the text to state: + Implementations SHOULD indicate their trusted Certification Authorities. For TLS 1.2, this is done using [RFC5246] section 7.4.4 "certificate authorities" (server side) and [RFC6066] Section 6 "Trusted CA Indication" (client side). See also Section 3.2. I'm wondering if I should also include exact pointers to the TLS 1.1 equivalents. After all TLS 1.1 is fading out anyway, so I could imagine to leave that as the famous "exercise to the reader" if he wants to use TLS 1.1 still. I wouldn't mind adding them explicitly though; just let me know what you think is preferable. > Note Section 3.4 (1) ) > Missing open paren? Right. Fixed to: 4. start exchanging RADIUS datagrams (note Section 3.4 (1) ). The shared secret to compute the (obsolete) MD5 integrity checks and attribute encryption MUST be "radsec" (see Section 3.4 (2) ). 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
- [Gen-art] Gen-ART Telechat Review of draft-ietf-r… Pete McCann
- Re: [Gen-art] Gen-ART Telechat Review of draft-ie… Stefan Winter
- Re: [Gen-art] Gen-ART Telechat Review of draft-ie… Russ Housley
- Re: [Gen-art] Gen-ART Telechat Review of draft-ie… Romascanu, Dan (Dan)