IP Flow Information Export (ipfix)

Gerhard Muenz | 6 Mar 2009 14:02

Picon

[IPFIX] IPFIX configuration: (D)TLS


Hi Brian,

Benoit reminded me that you promised some input regarding (D)TLS
parameters that might be included into the configuration data model.
http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt

Do you can still remember what you were thinking of?
Probably the Fully Qualified Domain Name?

If you are into this topic, maybe you can send a list with all common
parameters - just to get an overview - and those that are interesting to
have in the configuration data model. For example, I assume that it is
not interesting to configure certificates - these are probably provided
by different means to the devices.

Gerhard

--

-- 
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: muenz <at> net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz

Attachment (smime.p7s): application/x-pkcs7-signature, 3467 bytes

(Continue reading)

Brian Trammell | 6 Mar 2009 14:39

Picon

Picon

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

Hi, Gerhard,

The main parameters I was thinking of are keying and identity  
parameters. Perhaps we can state that CPs and EPs will be keyed  
offline, but at least it might be nice to change the names of the  
peers a device is willing to communicate with.

For TLS, at minimum, an EP or CP must know:

1. its CA certificates (PEM/DER)
2. CA certificates for its peers' certificates (PEM/DER) (if not using  
a single CA for all)
3. its own certificate and private key (PKCS#12)
4. the names of the peers it is willing to communicate with  
(subjectName string) (if not assuming signature by a known CA is  
sufficient)
5. CRL or OCSP peer for revocation, if supported (which it should be,  
though 5101 doesn't state this directly)

How much of that to support in config is an open question. Beyond that  
it gets a bit implementation-specific.

I hope to do a thorough review of the config work by San Francisco,  
though no promises, as it's a bit mad here at the moment. Will you be  
at the meeting?

Cheers,

Brian

(Continue reading)

Gerhard Muenz | 6 Mar 2009 15:15

Picon

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

Hi Brian,

Brian Trammell wrote:
> Hi, Gerhard,
> 
> The main parameters I was thinking of are keying and identity
> parameters. Perhaps we can state that CPs and EPs will be keyed offline,
> but at least it might be nice to change the names of the peers a device
> is willing to communicate with.

Who should restrict its willingness to communicate? The CP or the EP or
both?

Just using the name does not seem to be sufficient because the same name
could be used with several certificates, right?
So, it would be necessary to say: "CP accepts data from EP with name=X
authorized by certificate/CA Y".

Transporting certificates and keys to the devices does not seem to be
useful. However, if the device has several keys, it would be useful to
choose one of them.

It seems that we need kind of abstract identifiers for keys and
certificates saved on a device in order to refer to them in the
configuration.

> For TLS, at minimum, an EP or CP must know:
> 
> 1. its CA certificates (PEM/DER)

(Continue reading)

Brian Trammell | 6 Mar 2009 15:30

Picon

Picon

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


On Mar 6, 2009, at 3:15 PM, Gerhard Muenz wrote:

>
> Hi Brian,
>
> Brian Trammell wrote:
>> Hi, Gerhard,
>>
>> The main parameters I was thinking of are keying and identity
>> parameters. Perhaps we can state that CPs and EPs will be keyed  
>> offline,
>> but at least it might be nice to change the names of the peers a  
>> device
>> is willing to communicate with.
>
> Who should restrict its willingness to communicate? The CP or the EP  
> or
> both?

Per 5101, both.

> Just using the name does not seem to be sufficient because the same  
> name
> could be used with several certificates, right?
> So, it would be necessary to say: "CP accepts data from EP with name=X
> authorized by certificate/CA Y".

By "name" I mean the Subject DN (Distinguished Name) defined by X.509  
is suited for this purpose (see 4, below). An example DN (from your

(Continue reading)

Gerhard Muenz | 6 Mar 2009 16:08

Picon

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


Hi,

>>> The main parameters I was thinking of are keying and identity
>>> parameters. Perhaps we can state that CPs and EPs will be keyed offline,
>>> but at least it might be nice to change the names of the peers a device
>>> is willing to communicate with.
>>
>> Who should restrict its willingness to communicate? The CP or the EP or
>> both?
> 
> Per 5101, both.

Ok. Own name and accepted peer names could be configured per CP/EP.

>> Just using the name does not seem to be sufficient because the same name
>> could be used with several certificates, right?
>> So, it would be necessary to say: "CP accepts data from EP with name=X
>> authorized by certificate/CA Y".
> 
> By "name" I mean the Subject DN (Distinguished Name) defined by X.509 is
> suited for this purpose (see 4, below). An example DN (from your Thawte
> cert :) follows:
> 
> SN=Muenz, GN=Gerhard, CN=Gerhard
> Muenz/emailAddress=muenz <at> informatik.uni-tuebingen.de/emailAddress=muenz <at> net.in.tum.de
> 
> A CA SHOULD _never_ sign two different certificates with the same
> validity for the same subject without an intervening revocation;
> likewise nobody should ever treat the same certificate as useful for

(Continue reading)

Brian Trammell | 6 Mar 2009 16:11

Picon

Picon

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


On Mar 6, 2009, at 4:08 PM, Gerhard Muenz wrote:

>
> Hi,
>
>>>> The main parameters I was thinking of are keying and identity
>>>> parameters. Perhaps we can state that CPs and EPs will be keyed  
>>>> offline,
>>>> but at least it might be nice to change the names of the peers a  
>>>> device
>>>> is willing to communicate with.
>>>
>>> Who should restrict its willingness to communicate? The CP or the  
>>> EP or
>>> both?
>>
>> Per 5101, both.
>
> Ok. Own name and accepted peer names could be configured per CP/EP.
>
>>> Just using the name does not seem to be sufficient because the  
>>> same name
>>> could be used with several certificates, right?
>>> So, it would be necessary to say: "CP accepts data from EP with  
>>> name=X
>>> authorized by certificate/CA Y".
>>
>> By "name" I mean the Subject DN (Distinguished Name) defined by X. 
>> 509 is

(Continue reading)

Gerhard Muenz | 28 May 2009 21:53

Picon

[IPFIX] IPFIX configuration: (D)TLS authentication


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:

(Continue reading)

Gerhard Muenz | 25 Jun 2009 21:19

Picon

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


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

(Continue reading)

Return

Return to gmane.ietf.ipfix.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane