Subject: Re: [IPFIX] IPFIX configuration: (D)TLS authentication

From: Gerhard Muenz <[email-masked]>
Date: Thu, 25 Jun 2009 21:19:46 +0200

Hi all,

Coming back to the configuration of mutual authentication between
Exporting Processes and Collectiong Processes, please find below the
text that I plan to add to the draft.

Please comment.

We could add further parameters to the TransportLayerSecurity class if
necessary, e.g. to specify if message authentication or encryption is to
be used, the crypto-algorithm etc. I'm not sure, if the WG wants to go
that far.

Regards,
Gerhard

5.4.1.  Destination Class

     +-------------------------------------+
     | Destination                         |
     +-------------------------------------+   0..1 +-----------------+
     | [name]                              |<>------| TransportLayer- |
     | exportMemberType                    |        | Security        |
     | ipfixVersion                        |        +-----------------+
     | transportProtocol                   |
     | destinationIpAddress                |
     | destinationPort                     |
     | sourceIpAddress (UDP)               |
     | localIpAddress* (SCTP)              |
     | sendBufferSize                      |
     | rateLimit                           |
     | timedReliability (SCTP)             |
     | numberOfStreams (SCTP)              |
     | orderedDelivery (SCTP)              |
     | templateRefreshTimeout (UDP)        |
     | optionsTemplateRefreshTimeout (UDP) |
     | templateRefreshPacket (UDP)         |
     | optionsTemplateRefreshPacket (UDP)  |
     +-------------------------------------+

                       Figure 13: Destination class

[...]

   Using the TransportLayerSecurity class, transport layer security is
   enabled and configured for this export destination.  If the transport
   protocol is SCTP or UDP, transport layer security is realized using
   DTLS.  In the case of TCP, TLS is used instead.

[...]

5.5.1.  Receiver Class

       +--------------------------+
       | Receiver                 |
       +--------------------------+   0..1 +------------------------+
       | [name]                   |<>------| TransportLayerSecurity |
       | transportProtocol        |        +------------------------+
       | localIpAddress*          |
       | localPort                |
       | maxAllowedStreams (SCTP) |
       | templateLifetime (UDP)   |
       +--------------------------+

                         Figure 18: Receiver class

[...]

   Using the TransportLayerSecurity class, transport layer security
   using DTLS and TLS is enabled and configured for this listening
   socket of the Collecting Process.  If the transport protocol is SCTP
   or UDP, transport layer security is realized using DTLS.  In the case
   of TCP, TLS is used instead.

[...]

5.6.  Transport Layer Security Class

                    +---------------------------------+
                    | TransportLayerSecurity          |
                    +---------------------------------+
                    | offeredCertificateAuthorityDN*  |
                    | offeredSubjectDN*               |
                    | offeredSubjectFQDN*             |
                    | acceptedCertificateAuthorityDN* |
                    | acceptedSubjectDN*              |
                    | acceptedSubjectFQDN*            |
                    +---------------------------------+

                  Figure 20: TransportLayerSecurity class

   The TransportLayerSecurity class can be used in the Exporting
   Process's Destination class and the Collecting Process's Receiver
   class to enable and configure transport layer security for IPFIX.
   Depending on the transport protocol, DTLS or TLS are used as
   specified in [RFC5101].  The mutual authentication of Exporting
   Processes and Collecting Process can be controlled by the following
   parameters:

   offeredCertificateAuthorityDN:  This parameter restricts
      authentication of the local endpoint during the TLS/DTLS handshake
      to X.509 certificates issued by the given certificate authority.
      The parameter contains the distinghished name of the certificate
      authority.
      The parameter MAY appear multiple times to specify a list of
      certificate authorities whose certificates can be used by the
      local endpoint.  Certificates issued by any certificate authority
      that is not contained in the list MUST NOT be sent to the remote
      peer during TLS/DTLS handshake.
      If offeredCertificateAuthorityDN is not configured, the local
      endpoint may use certificates of any certificate authority for
      authentication.
   offeredSubjectDN, offeredSubjectFQDN:  These parameters restrict
      authentication of the local endpoint during the TLS/DTLS handshake
      to X.509 certificates issued for a specific subject.
      offeredSubjectDN contains a distinghished name which identifies
      the local endpoint; this distinghished name is included in the
      subject of the X.509 certificate. offeredSubjectFQDN contains a
      fully-qualified domain name which is assigned to the local
      endpoint; this fully-qualified domain name is included in the
      dNSName of the subject alternative extension field or in the
      commonName of the subject field of the X.509 certificate as
      specified in [RFC5101].
      Both parameters MAY appear multiple times to specify a list of
      subjects and fully-quailfied domain names the local endpoint is
      allowed to use to authenticate itself.  X.509 certificates sent to
      the remote peer during TLS/DTLS handshake MUST contain one of the
      specified distinghished names in the subject field or at least one
      of the specified fully-qualified domain names in the dNSName of
      the subject alternative extension field or in the common name of
      the subject field.  The Monitoring Device MUST ensure that the
      X.509 certificate actually identifies the local endpoint before
      sending it to the remote peer.
      If any of the parameters offeredSubjectDN and offeredSubjectFQDN
      is configured at the same time as the
      offeredCertificateAuthorityDN parameter, certificates MUST also
      fulfill the specified restrictions regarding the certificate
      authority.
      If offeredSubjectDN and offeredSubjectFQDN are not configured, the
      local endpoint may use certificates with any distinguished name or
      fully-qualified domain name.
   acceptedCertificateAuthorityDN:  This parameter restricts
      authentication of the remote peer during the TLS/DTLS handshake to
      X.509 certificates issued by the given certificate authority.  The
      parameter contains the distinghished name of the certificate
      authority.
      The parameter MAY appear multiple times to specify a list of
      certificate authorities whose certificates are accepted.
      Certificates issued by any certificate authority that is not
      contained in the list MUST be rejected during TLS/DTLS handshake.
      If acceptedCertificateAuthorityDN is not configured, certificates
      of any certificate authority are accepted.
   acceptedSubjectDN, acceptedSubjectFQDN:  These parameters restrict
      authentication of remote peers during the TLS/DTLS handshake to
      X.509 certificates issued for a specific subject.
      acceptedSubjectDN contains a distinghished name that is accepted
      in the subject field of the X.509 certificate. acceptedSubjectFQDN
      contains a fully-qualified domain name that is accepted in the
      dNSName of the subject alternative extension field or in the
      commonName of the subject field of the X.509 certificate as
      specified in [RFC5101].
      Both parameters MAY appear multiple times to specify a list of
      accepted subjects and fully-quailfied domain names.  A X.509
      certificate received during TLS/DTLS handshake from the remote
      peer MUST only be accepted if it contains one of the specified
      distinghished names in the subject field or at least one of the
      specified fully-qualified domain names in the dNSName of the
      subject alternative extension field or in the common name of the
      subject field.
      If any of the parameters acceptedSubjectDN and acceptedSubjectFQDN
      is configured at the same time as the
      acceptedCertificateAuthorityDN parameter, certificates MUST also
      fulfill the specified restrictions regarding the certificate
      authority in order to be accepted.
      If acceptedSubjectDN and acceptedSubjectFQDN are not configured,
      any distinguished name and any fully-qualified domain name
      belonging to the remote peer are accepted.

   Note that transport layer security can be enabled without configuring
   any of the parameters.  In this case, an empty XML element
   <transportLayerSecurity /> appears in the configuration.

Gerhard Muenz wrote:
> Hi all,
> 
> Regarding the configuration of (D)TLS, one of my students pointed out
> that RFC 5101 specifies to authenticate Exporting and Collecting
> Processes by FQDNs:
> 
> 11.3. Authentication
> 
>    IPFIX Exporting Processes and IPFIX Collecting Processes are
>    identified by the fully qualified domain name of the interface on
>    which IPFIX Messages are sent or received, for purposes of X.509
>    client and server certificates as in [RFC3280].
> 
> The FQDN can be stored in a subjectAltName extension or the Common Name
> field of the X.509 certificate. subjectAltName seems to be the preferred
> solution.
> 
> RFC 5101 says:
> 
>    Each of the IPFIX Exporting and
>    Collecting Processes MUST verify the identity of its peer against its
>    authorized certificates, and MUST verify that the peer's certificate
>    matches its fully qualified domain name, or, in the case of SCTP, the
>    fully qualified domain name of one of its endpoints.
> 
> I assume that the configuration data model should enable the
> configuration of which certificates are "authorized".
> In general, I see three cases:
> 
> 1) any valid certificate is authorized
> 2) only a valid certificate issued by one out of a given list of CAs is
> authorized
> 3) only a valid certificate for one out of a given list of FQDNs issued
> by one out of a given list of CAs is accepted
> 
> So, I would add the following parameters at appropriate places to the
> Exporting Process and Collecting Process parameter sets:
> 
> - certificateAuthority: Common Name of the accepted CA
> - [collectingProcess|exportingProcess]DomainName: FQDN of accepted CP|EP
>   (without specifying if the FQDN is expected to appear in the CN field
>    of the Subject or in the subjectAltName extension)
> 
> I hope that the Common Name is enough to identify the CA unambiguously.
> 
> How about endpoints that have multiple certificates available (e.g.,
> issued by different CAs)? In this case, it might be interesting to
> configure which certificate(s) the endpoint should offer the other
> endpoint for identification.
> 
> So, we would be able to specify both certificates _used_ and
> certificates _accepted_ by an Exporting Process or Collection Process.
> 
> Opinions?
> 
> BTW, the second part of the above quote from RFC5101 ("MUST verify that
> the peer's certificate matches its fully qualified domain name") seems
> to require a DNS lookup, or how is it supposed to work?
> 
> Regards,
> Gerhard
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz