Re: Comments on draft-ietf-radext-radsec-02 for WGLC

[Stefan Winter <stefan.winter@restena.lu>]

Hi, Joe,

thanks for the review!
> Here are some working group last call comments on RADSEC:
>
> 1.  How is backward compatibility/forward migration of RADSEC handled?
> Operational recommendations in this area should be discussed.   The
> potential for rollback attacks should also be covered in the security
> considerations section.
>   

True. I had hoped to offload backward compatibility to the TCP transport
document, since this is the one with the new transport. But since TCP
w/o TLS and TCP with TLS have different port numbers, a distinct issue
is raised between the two. Effectively, both tcp-transport and radsec
need to have their own backwards compatibility section. I will add text
to the next revision, also for the security considerations.

> 2.  I think the certificate handling and authorization section needs to
> be more specific for supporting mandatory to implement options.
> Currently, the document implicitly requires trust root based
> authorization where all certs issued by a given trust root are
> authorized.  Some more specific rules are discussed in an informative
> section.  I believe some of this needs to be normative and more specific
> in order to have interoperable implementations.  This should also be
> discussed in the security considerations.
>   

The hesitance against mandating specific options is historic from when I
thought this would only become an informational description. I'll
merrily promote the check options mentioned in the document to
mandatory-to-implement. A revised draft will follow.

> 3.  I'm not sure I understand the choice of ciphersuites.
>
> Why is TLS_RSA_WITH_RC4_128_SHA recommended?  It seems that it would be
> much preferable to use AES or 3DES? 
>   

Hm... This was a first shot :-) I can't brag about being a cipher suite
expert. Can you create a list of suggested cipher suites?

> 4.  The document should state that the fixed string "radsec" shared
> secret MUST NOT be used when TLS is not available.  
>   

I fully agree that using a fixed, well-known shared secret is suicidal
when not using TLS. I'm not sure though if it needs to be in this
document though... the document specifies how to behave when *doing*
TLS. People who implement TCP only (without RadSec) wouldn't necessarily
read the RadSec document anyway. So I'm not sure if it makes sense to
write it down here. It makes much sense though to add this word of
warning to tcp-transport though. So... any particular opinion in the
group about adding this or not?

> 5. The terms "dynamic peer resolution" and "dynamic peer discovery" are
> used in the document and not clearly defined.  
>   

The whole dynamic discovery will be moved to a separate document, as
discussed in MSP. That other document should clearly define this though,
agreed.

> 6. Would RADSEC benefit from a mechanism that did not require a PKI?
> This could be achieved by specifying a certificate fingerprint or PSK
> mode of operation.  
>   

I'm almost certain it would! There are certainly deployment scenarios
where a PKI rollout could be seen as "overkill". I tried to formulate
the draft PKI-agnostic, saying "*When using X.509 certificates* in the
"Connection Setup" section, hoping to imply that any other way of
establishing a TLS connection, like with a PSK, is not excluded. I can
make this more explicit though.

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


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>