Subject: I-D Action:draft-ietf-radext-radsec-07.txt

From: [email-masked]
Date: Mon, 12 Jul 2010 05:15:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : TLS encryption for RADIUS
	Author(s)       : S. Winter, et al.
	Filename        : draft-ietf-radext-radsec-07.txt
	Pages           : 18
	Date            : 2010-07-12

This document specifies security on the transport layer (TLS) for the
RADIUS protocol when transmitted over TCP.  This enables dynamic
trust relationships between RADIUS servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 12 Jul 2010 14:21:24 +0200

Hi,

this rev should fix trac item #4, and all except two points in #3:

- Client identity: which parts of a certificate are relevant
- RADIUS/TLS cleint vs. server: packet type restrictions

(the caption of  #3 suggests that there is a "Part 2" of the review
pending?)

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 12 Jul 2010 15:27:08 +0200

> this rev should fix trac item #4, and all except two points in #3:

  I'd also suggest auditing it for "RADIUS over FOO".  That should be
changed to "RADIUS/Foo"

  e.g.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 12 Jul 2010 15:33:59 +0200

I'd also suggest auditing it for "RADIUS over FOO".  That should be
changed to "RADIUS/Foo", e.g.

2.  Normative: Transport Layer Security for RADIUS over TCP

  to

2.  Normative: Transport Layer Security for RADIUS/TCP

  and

8.  Acknowledgements

   RADIUS over TLS ...

to

   RADIUS/TLS

  and

RADIUS has no notion of negotiating TLS in an established connection.
Servers and clients need to be preconfigured to use RADIUS/TLS for a	
given endpoint.

   to

RADIUS/TLS has no notion of ....

  Also, the reference names could be changed:

[I-D.dekok-radext-tcp-transport]  is now "draft-ietf".  Not a big issue,
but useful to change.

  There should also be an RFC editor note that the draft has a normative
requirement on the TCP transport draft.

  The "connection backoff" algorithm should really be standardized:

   The proxy will at startup try to establish a TLS connection to each
   (if any) of the configured RadSec (TLS) servers.  If it fails to
   connect to a server, it will retry regularly.  There is some back-off
   where it will retry quickly at first, and with longer intervals
   later.

  See the Status-Server draft, which had a lot of feedback over the
backoff algorithms it discussed.  I'm not proposing to use the same
method here.  I'm suggesting that *something* should be defined,
otherwise other reviewers will suggest defining the backoff algorithm.

  The backoff algorithm should also be mentioned in the "Security
Considerations" section.  Bad clients that hammer a server can result in
a DoS attack.