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

[Russ Housley <[e-mail]>]

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