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

From: Gerhard Muenz <[email-masked]>
Date: Fri, 06 Mar 2009 14:02:14 +0100

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

---

From: Brian Trammell <[email-masked]>
Date: Fri, 6 Mar 2009 14:39:48 +0100

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

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 06 Mar 2009 15:15:49 +0100

Hi Brian,

Brian Trammell wrote:
> 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.

> 2. CA certificates for its peers' certificates (PEM/DER) (if not using a
> single CA for all)
> 4. the names of the peers it is willing to communicate with (subjectName
> string) (if not assuming signature by a known CA is sufficient)
> though no promises, as it's a bit mad here at the moment. Will you be at
> the meeting?

No, unfortunately not.

Cheers,
Gerhard

---

From: Brian Trammell <[email-masked]>
Date: Fri, 6 Mar 2009 15:30:33 +0100

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

>> offline,

Per 5101, both.

> 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=[email-masked] 
/emailAddress=[email-masked]

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  
multiple entities at the DN level.

> certificates saved on a device in order to refer to them in the

X.509 DNs are used for this purpose. CNs (Common Names) can be used  
for this in practice, but this is not recommended.

Cheers,

Brian

>> (subjectName

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 06 Mar 2009 16:08:37 +0100

Hi,

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

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

> 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=[email-masked]/emailAddress=[email-masked]
> 

Ok, as long you have a single CA. With two CAs, there can be two
certificates with the same name for different subjects.
But you usually trust the CAs and their practice to issue certificates :)

Gerhard

> X.509 DNs are used for this purpose. CNs (Common Names) can be used for
> this in practice, but this is not recommended.
> 
> Cheers,
> 
> Brian
>

---

From: Brian Trammell <[email-masked]>
Date: Fri, 6 Mar 2009 16:11:03 +0100

> But you usually trust the CAs and their practice to issue  

In this case, you can qualify the DN of the Subject with the DN of the  
Issuer (CA), and you have a (theoretically :) ) globally unique  
identifier...

>> for