Re: [secdir] [radext] Security review of draft-ietf-radext-radsec

[Stefan Winter <[e-mail]>]

Hi,

> Hi.  I'm not the secdir reviewer assigned to this draft, but felt that
> this draft needed additional security review, so I decided to perform a
> secdir-like review.
> 
> Overall, I think this is a much-needed specification and believe it is
> mostly ready for publication as an experimental RFC. I'd say a bit more
> clarity would be required if we wanted to move this to the standards
> track.

Thanks for the review!

> General issues:
> 
> 1) I'm reasonably sure that RADSEC MUST NOT be used with TLS versions
> prior to 1.1. The concern I have is that RADSEC has long-lived TLS
> connections under which an attacker could potentially observe ciphertext
> generated from some plaintext before sending additional plaintext.  TLS
> 1.1 includes explicit IVs that prevent various attacks  that may happen
> against earlier versions of TLS.
> There are implementation work arounds that can also prevent these
> attacks. However since all RADSEC implementations are required to
> support TLS 1.1, I'd prefer to add a requirement that RADSEC
> implementations MUST NOT negotiate TLS versions prior to 1.1 in order to
> avoid this issue.

That's a very useful comment, thanks! TLS 1.1 was marked as
minimum-required to prevent these attacks (IIRC). But of course it might
happen that even though both sides *support* TLS 1.1, they don't
actually negotiate it.

I've added corresponding text in my working copy, which will become -12
soon:

       *  Support for TLS v1.1 [RFC4346] or later (e.g.  TLS 1.2
          [RFC5246] ]) is REQUIRED.  To prevent known attacks on TLS
          versions prior to 1.1, implementations MUST NOT negotiate TLS
          versions prior to 1.1.


> 2) Section 2.3 implies that you need to do cert validation all the time,
> even when you have a certificate fingerprint. I think it could more
> clearly indicate that multiple ways of figuring out if you have the
> right public key are provided.  It's also not clear to me from section
> 2.3 whether there is a mandatory-to-implement strategy. You SHOULD
> support cert fingerprints. You MUST support cert path validation, but is
> there a required name form to support? There are discussions of several
> name forms but none seem mandatory. I see no discussion of RFC 6125,
> which I would have expected to see here.  However, most of this is OK
> for an experimental spec.  This is the big area where I'd expect to see
> more clarity before this could move to the standards track.

Agreed that there's a bit of an option bloat in the cert validation
sections, and that there should be more guidance for standards track if
the spec gets there.

There's one thing I'd like to fix for the current document though. It
was not really my intention to enforce e.g. 5280 checks when
fingerprint-based operation is in place. My role-model existing
deployment of fingerprint-based validation is SAML2 metadata. There, an
entity can get identified by its fingerprint alone; regardless of other
properties of the certificate (e.g. it doesn't matter whether the
certificate is expired, or what CA it comes from - so lang as the
configured fingerprint matches the incoming cert's fingerprint, it's fine).

In the SAML world, that mode of operation seems to be popular; I
wouldn't want to preclude that same model of operation here.

I'll reformulate that section to make clearer that PKIX-style cert
validation is one thing, and that manually configured fingerprints is
another (and TLS-PSK is yet another thing, of course). How about this:


   3.  Peer authentication can be performed in any of the following
       three operation models:

       *  TLS with X.509 certificates using PKIX trust models (this
          model is mandatory to implement):

          +  Implementations MUST allow to configure a list of trusted
             Certification Authorities for incoming connections.

          +  Certificate validation MUST include the verification rules
             as per [RFC5280].

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

          +  Peer validation always includes a check on whether the
             locally configured expected DNS name or IP address of the
             server that is contacted matches its presented certificate.
             DNS names and IP addresses can be contained in the Common
             Name (CN) or subjectAltName entries.  For verification,
             only one of 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.

       *  TLS with X.509 certificates using certificate fingerprints
          (this model is optional to implement): Implementations SHOULD
          allow to configure a list of trusted certificates, identified
          via certificate fingerprint.  Implementations MUST support
          SHA-1 as the hash algorithm.

       *  TLS using TLS-PSK (this model is optional to implement)

(note that some changed to this text might occur due to pending
DISCUSSes and COMMENTs in the IESG review).

Greetings,

Stefan Winter

> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext


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