Subject: Issue 282: cert validation, proposed text

From: Stefan Winter <[email-masked]>
Date: Wed, 11 Feb 2009 10:12:45 +0100

Hi,

> 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. 
>   

Section 2.2 now reads:

2.2.  Connection Setup

   RadSec nodes

   1.  establish TCP connections as per [I-D.dekok-radext-tcp-transport]

   2.  negotiate TLS sessions according to [RFC5246] or its predecessor
       TLS 1.1.  The following restrictions apply:

       *  The authentication MUST be mutual, i.e. both the RadSec server
          and the RadSec client authenticate each other.

       *  The client MUST NOT negotiate cipher suites which only provide
          integrity protection.

       *  The TLS session MAY use mutual PSKs for connection setup.

       *  The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be
          supported.

       *  The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and
          TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2
          (1) )

   3.  If TLS is used in an X.509 certificate based operation mode, the
       following list of certificate validation options applies:

       *  Implementations MUST allow to configure a list of acceptable
          Certification Authorities for incoming connections.

       *  Certificate validation MUST include the verification rules as
          per [RFC5280].  If an SRV entry is present in the certificate
          and dynamic discovery based on DNS is used, the SRV entry
          SHOULD be validated. refence x.y.z here.

       *  Implementations SHOULD indicate their acceptable Certification
          Authorities as per section 7.4.4 (server side) and x.y.z
          ["Trusted CA Indication"] (client side) of [RFC5246] (see
          Section 3.1 (1) )

       *  Implementations SHOULD allow to configure a list of acceptable
          certificates, identified via certificate fingerprint.

       *  Peer validation always includes a check on whether the DNS
          name or the IP address of the server that is contacted matches
          its certificate.  DNS names and IP addresses can be contained
          in the Common Name (CN) or subjectAltName entries.  For
          verification, only one these entries is to be considered.  The
          following precedence applies: for DNS name validation,
          subjectAltName:DNS has precedence over CN; for IP address
          validation, subjectAltName:iPAddr has precedence over CN.

       *  Implementations SHOULD allow to configure a set of acceptable
          values for subjectAltName:URI.

There's no additional text in Security Considerations since was not sure
if additional text was needed with this new text.

Please comment if this text can satisfactorily close this sub-issue.

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

---

From: Stefan Winter <[email-masked]>
Date: Wed, 11 Feb 2009 10:12:57 +0100

Hi,

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

The terms have been unified and clarified by referencing a (new)
separate draft on dynamic peer discovery (which doesn't exist yet, but
will be submitted soon).

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 11 Feb 2009 10:12:53 +0100

Hi,

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

I propose to add text to tcp-transport and volunteer for writing it.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 11 Feb 2009 10:13:01 +0100

Hi,

> 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.  
>   

The text in 2.2 has been clarified that a TLS PSK operation mode is
allowed. Cert fingerprint as a means of validating a connection attempt
has been added as a SHOULD.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 11 Feb 2009 10:12:49 +0100

Hi,

> 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? 
>   

I could use a little help here. Is there anyone willing to investigate
cipher suite selection? An alternative would be to follow the path of
e.g. the EAP tunnel reqs, which cite NIST references for acceptable
cipher suites...

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 11 Feb 2009 10:12:40 +0100

Hi,

> 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.  
>   

Section 4 of the new -03 revision reads:

4.  Compatibility with other RADIUS transports

   Ongoing work in the IETF defines multiple alternative transports to
   the classic UDP transport model as defined in [RFC2865], namely
   RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS
   [I-D.dekok-radext-dtls] and the present document on RadSec.

   RadSec does not specify any inherent backwards compatibility to
   classic RADIUS or cross compatibility to the other transports, i.e.
   an implementation which implements RadSec only will not be able to
   receive or send RADIUS packet payloads over other transports.  An
   implementation wishing to be backward or cross compatible (i.e.
   wishes to serve clients using other transports than RadSec) will need
   to implement the other transports and RadSec transport and be
   prepared to send and receive on all implemented transports, which is
   called a multi-stack implementation.

   If a given IP device is able to receive RADIUS payloads on multiple
   transports, this may or may not be the same instance of software, and
   it may or may not serve the same purposes.  It is not safe to assume
   that both ports are interchangeable.  In particular, it can not be
   assumed that state is maintained for the packet payloads between the
   transports.  Two such instances MUST be considered separate RADIUS
   server entities.

   As a consequence, the selection of transports to communicate from a
   client to a server is a manual administrative action.  An automatic
   fallback to classic RADIUS is NOT RECOMMENDED, as it may lead to
   down-bidding attacks on the peer communication.

And the Security Consideration contains:

   If peer communication between two devices is configured for both
   RadSec and classic RADIUS, a failover from RadSec to classic RADIUS
   opens the way for a down-bidding attack if an adversary can
   maliciously close the TCP connection, or prevent it from being
   established.  In this case, security of the packet payload is reduced
   from the selected TLS cipher suite packet encryption to the classic
   MD5 per-attribute encryption.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 16 Feb 2009 21:34:49 -0800

Hi Stefan,

This looks good.

Thanks,

Joe

> -----Original Message-----
> From: Stefan Winter [mailto:[email-masked]] 
> Sent: Wednesday, February 11, 2009 1:13 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: Issue 282: backward compatibility, proposed text
> 
> Hi,
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 16 Feb 2009 21:48:38 -0800

You could just leave this to the TLS specification.  For version 1.0 and 1.1 it is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and for 1.2 it is TLS_RSA_WITH_AES_128_CBC_SHA.   If it is common today for implementations also to implement the RC4 ciphers you can have that as a recommendation as well.  Something like:

"RADSEC implementation MUST support he mandatory to implement cipher suites specified in TLS.  For purposes of compatibility with some current deployments implementations SHOULD support TLS_RSA_WITH_RC4_128_SHA as well." 

Cheers,

Joe 

> Subject: Issue 282: cipher suites, discussion needed
> 
> Hi,
> 
> > Why is TLS_RSA_WITH_RC4_128_SHA recommended?  It seems that 
> it would 
> > be much preferable to use AES or 3DES?
> >   
> 
> I could use a little help here. Is there anyone willing to 
> investigate cipher suite selection? An alternative would be 
> to follow the path of e.g. the EAP tunnel reqs, which cite 
> NIST references for acceptable cipher suites...
> 
> 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: Bernard Aboba <[email-masked]>
Date: Mon, 16 Feb 2009 22:59:55 -0800

> down-bidding attacks on the peer communication.

Question:  At various points we have talked about separating out the material on DNS SRV-based discovery.  How does this recommendation relate to that?  For example, assuming that DNS SRV RR queries aren't protected by DNSSEC, couldn't the discovery process generate a "fallback to classic RADIUS"? (e.g. if only the FQDN of the server is provided and DNS SRV RR queries are used to determine whether RADSEC and/or RADIUS was supported).   For example, couldn't an attacker spoof a response to the DNS SRV RR query and convince the querier that only RADIUS was available?  

> Please comment if this text can satisfactorily close this sub-issue.

I think you need to say a bit more about the assumed deployment model and configuration/discovery.  For example, that RADSEC is deployed for use by proxies in talking to each other, and that as a result, these proxies *only* talk RADSEC.  It's a bit trickier if a NAS is capable of speaking both RADSEC and RADIUS.  In that situation it seems that the NAS would be configured to speak one or the other to a given RADIUS server, and that DNS-based discovery would play no role.  Is that right?   Is this advice still true if the RADIUS client has a DNSSEC-validating stub resolver and therefore is able to do secure discovery? 

In the discussion of RADIUS over DTLS, there had been discussion of the ability to distinguish RADIUS/DTLS from RADIUS on the fly.  So I'm wondering if this advice on manual configuration applies there too, or not. 

And overall, I'm curious about where the text relating to DNS discovery is going/belongs.  In the draft?  Outside of it in a separate document?  None of these?

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 Feb 2009 23:03:39 -0800

Yes, in general it's a good idea to acknowledge that TLS implementations need to implement the mandatory-to-implement ciphersuites for the versions they support.   With respect to NIST guidance, I'm a bit puzzled  (e.g. SP 800-120 seems to imply that the 1.1 mandatory-to-implement ciphersuite is ok, but the 1.2 one is not).  

> Subject: RE: Issue 282: cipher suites, discussion needed
> Date: Mon, 16 Feb 2009 21:48:38 -0800
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 17 Feb 2009 08:15:06 +0100

Bernard Aboba wrote:
> Question:  At various points we have talked about separating out the
> material on DNS SRV-based discovery.  How does this recommendation
> relate to that?  For example, assuming that DNS SRV RR queries aren't
> protected by DNSSEC, couldn't the discovery process generate a "fallback
> to classic RADIUS"?

  Yes.

> (e.g. if only the FQDN of the server is provided and
> DNS SRV RR queries are used to determine whether RADSEC and/or RADIUS
> was supported).   For example, couldn't an attacker spoof a response to
> the DNS SRV RR query and convince the querier that only RADIUS was
> available? 

  Systems should be implemented so that administrators can require
RADSEC for particular home servers.  This turns the down-bidding attack
into a DoS attack, as the proxy will refuse to connect over plain RADIUS.

> I think you need to say a bit more about the assumed deployment model
> and configuration/discovery.  For example, that RADSEC is deployed for
> use by proxies in talking to each other, and that as a result, these
> proxies *only* talk RADSEC.

  And are configured to require RADSEC.

>  It's a bit trickier if a NAS is capable of
> speaking both RADSEC and RADIUS.  In that situation it seems that the
> NAS would be configured to speak one or the other to a given RADIUS
> server, and that DNS-based discovery would play no role.  Is that
> right?

  Likely, yes.  However, it may be simple for clients to use SRV
lookups, too, as it avoids manual reconfiguration when the network
changes.  Clients should also be configurable to require RADSEC.

  If you assume that the client DNS lookups are performed over a
"secure" administrative network, then DNSSEC may not be required.

>   Is this advice still true if the RADIUS client has a
> DNSSEC-validating stub resolver and therefore is able to do secure
> discovery?

  Dynamic discover is always useful, and should be implemented where
possible.

> In the discussion of RADIUS over DTLS, there had been discussion of the
> ability to distinguish RADIUS/DTLS from RADIUS on the fly.  So I'm
> wondering if this advice on manual configuration applies there too, or not.

  Yes.

> And overall, I'm curious about where the text relating to DNS discovery
> is going/belongs.  In the draft?  Outside of it in a separate document? 
> None of these?

  In a separate draft.  DTLS and normal RADIUS could be using dynamic
discovery, too.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 17 Feb 2009 19:42:22 +0700

Joseph Salowey [mailto:[email-masked]] writes:

> You could just leave this to the TLS specification.  For version 1.0
> and 1.1 it is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and for 1.2 it is
> TLS_RSA_WITH_AES_128_CBC_SHA.   If it is common today for
> implementations also to implement the RC4 ciphers you can have that as
> a recommendation as well.  Something like:
> 
> "RADSEC implementation MUST support he mandatory to implement cipher
> suites specified in TLS.  For purposes of compatibility with some
> current deployments implementations SHOULD support
> TLS_RSA_WITH_RC4_128_SHA as well."

Seems like a good idea to me.

---

From: Stefan Winter <[email-masked]>
Date: Wed, 18 Feb 2009 14:25:12 +0100

Hi,

> Seems like a good idea to me.

Great! I'll update the document with this text and will likely post a
new revision before the SF cutoff date.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 18 Feb 2009 14:30:12 +0100

Hi,

> protected by DNSSEC, couldn't the discovery process generate a
> "fallback to classic RADIUS"? (e.g. if only the FQDN of the server is
> provided and DNS SRV RR queries are used to determine whether RADSEC
> and/or RADIUS was supported).   For example, couldn't an attacker
> spoof a response to the DNS SRV RR query and convince the querier that
> only RADIUS was available?

DNSSEC could secure the SRV response, yes. The overall security of
discovery also depends on the subsequent A/AAAA lookups, and I think
there's a loophole DNSSEC can't close. Which would in turn mean that
adding DNSSEC doesn't completely secure the process in the end, and so
manual configuration of a desired minimum security level is the only
proper answer. In the (yet unpublished) dynamic discovery draft, I've
just scribbled down the following (the second para relating to bidding
down):

   When using DNS without security, the replies to NAPTR, SRV and A/AAAA
   requests as described in section Section 2 can not be trusted.
   RADIUS transports have an out-of-DNS-band means to verify that the
   discovery attempt led to the intended target (TLD/DTLS: ceritifcate
   verification or TLS shared secret ciphers; UDP/TCP: the RADIUS shared
   secret) and are safe from DNS-based redirection attacks.  [Note:
   assuming here that a hypothetical RADIUS/UDP SRV discovery will NOT
   deliver the shared secret in the DNS response!]

   The discovery process is always susceptible to bidding down attacks
   if a realm has SRV records for RADIUS/UDP and/or RADIUS/TCP as well
   as for RADIUS/TLS and/or RADIUS/DTLS.  While the SRV query will
   expose both transports, an attacker in the routing path might
   suppress the subsequent A/AAAA results for the TLS or DTLS peer and
   trick the inititating peer into using the weakly protected UDP or TCP
   transports.  The use of DNSSEC can not fully mitigate this attack,
since it
   does not provide a means to detect packet suppression.  The only way
   to disable such bidding down attacks is by intiating connections only
   to the peer(s) which match or exceed a configured minimum security
   level.  An implementation SHOULD provide a means to configure the
   administratively desired minimum security level.

Does that make sense?

Greetings,

Stefan Winter

---

From: Stefan Winter <[email-masked]>
Date: Wed, 18 Feb 2009 15:33:59 +0100

>> protected by DNSSEC, couldn't the discovery process generate a "fallback

*If* classic RADIUS were to be specified with DNS SRV discovery, yes.
AFAIK, there are no plans to do that - only TLS and DTLS. It would be
rather tricky to do so, because the shared secret would need to be
discovered, and the DNS channel offers no adequate protection for such a
keying material exchange, AFAICT.

> into a DoS attack, as the proxy will refuse to connect over plain RADIUS.

That sounds good. Configuration details are not a part of the on-wire
protocol though, so: does it make sense to recommend this in the draft?
This sounds like an issue to mention in the dynamic discovery draft
itself (see below).

>   In a separate draft.  DTLS and normal RADIUS could be using dynamic

I have a stub of a draft on my disk, which is basically copy&paste from
the contents of the earlier radsec-02 revision. The issues discussed in
this thread (+i18n) should/will end up there.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473