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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
