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