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

From: Pete McCann <[email-masked]>
Date: Mon, 30 Jan 2012 22:17:30 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-radext-radsec-11
Reviewer: Peter McCann
Review Date: 2012-01-30
IETF LC End Date:
IESG Telechat date: 2012-02-02

Summary: 2 minor issues

Major issues: none

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

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.

Nits/editorial comments:

Section 2.3:
   x.y.z
Did you mean to fill in a real section number here?

   Note Section 3.4 (1) )
Missing open paren?

---

From: Stefan Winter <[email-masked]>
Date: Tue, 31 Jan 2012 08:41:41 +0100

Hello,

thanks for your review!

>    by the tuple (serial number of presented client certificate;Issuer).

Right, thanks for spotting; fixed now in my working copy.

> inherited from the referenced TCP specification?  It may be helpful to

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.

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

> 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