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

Stefan Winter <> Tue, 31 January 2012 07:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D7D821F85D6 for <>; Mon, 30 Jan 2012 23:41:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.408
X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5DpMsqaN8i96 for <>; Mon, 30 Jan 2012 23:41:49 -0800 (PST)
Received: from ( [IPv6:2001:a18:1::62]) by (Postfix) with ESMTP id 4FA1621F84B5 for <>; Mon, 30 Jan 2012 23:41:48 -0800 (PST)
Received: from (localhost []) by (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 (Postfix) with ESMTPS id 4C6B710581; Tue, 31 Jan 2012 08:41:46 +0100 (CET)
Message-ID: <>
Date: Tue, 31 Jan 2012 08:41:41 +0100
From: Stefan Winter <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Pete McCann <>
References: <>
In-Reply-To: <>
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
Subject: Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-radext-radsec-11
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Jan 2012 07:41:50 -0000


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).
>    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
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) ).


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