Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-radext-radsec-11

Russ Housley <housley@vigilsec.com> Wed, 29 February 2012 19:04 UTC

Return-Path: <housley@vigilsec.com>
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 0122021F87AB for <gen-art@ietfa.amsl.com>; Wed, 29 Feb 2012 11:04:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level:
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 W+6KsklthZtL for <gen-art@ietfa.amsl.com>; Wed, 29 Feb 2012 11:04:55 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id D407821F866B for <gen-art@ietf.org>; Wed, 29 Feb 2012 11:04:53 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B704CF2403F; Wed, 29 Feb 2012 14:05:19 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id yoBlMnO-pT3S; Wed, 29 Feb 2012 14:04:18 -0500 (EST)
Received: from [192.168.2.104] (pool-96-241-165-215.washdc.fios.verizon.net [96.241.165.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7FB38F24035; Wed, 29 Feb 2012 14:05:18 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <4F279B35.9010409@restena.lu>
Date: Wed, 29 Feb 2012 14:04:51 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2F2B210-D61C-42A1-A947-B59414A36687@vigilsec.com>
References: <CACvMsLGwVVF3x92O7j-eBjC4_PZ2EC_DuP-pgi1E-4-XkqT6SA@mail.gmail.com> <4F279B35.9010409@restena.lu>
To: Pete McCann <mccap@petoni.org>
X-Mailer: Apple Mail (2.1084)
Cc: IETF Gen-ART <gen-art@ietf.org>, Dan Romascanu <dromasca@gmail.com>
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: Wed, 29 Feb 2012 19:04:56 -0000

Pete:

I did not see a response to this message.  Do these changes resolve your concerns?

Russ


On Jan 31, 2012, at 2:41 AM, Stefan Winter wrote:

> 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 mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art