Subject: [Syslog] Some revised text for syslog TLS

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 23 May 2008 11:40:52 -0700

I reworked some of the text to try to capture the discussions in the
working group.  I broke out the mechanical part of the validation from
the policy.  There is some redundancy between the security
considerations section and the new policy section. I tried to focus the
requirements language on implementation requirements to enable secure
interoperability vs. deployment options.  We are not finished yet, but I
think it is a step in the right direction.  

Cheers,

Joe

4.2.1 Certificate-Based Authentication

Both syslog transport sender (TLS Client) and syslog transport receiver
(TLS server) MUST implement certificate-based authentication. This
consists validating proof of possession of the private key corresponding
to the public key in the certificate.  To ensure interoperability
between clients and servers, the following methods for certificate
validation are mandatory to implement:

   o  Certificate path validation: the client is configured with one or
more trust anchors.  Additional policy controls needed for authorizing
the syslog transport sender and syslog transport receiver are described
in Section 5.  This method is useful where there is a PKI deployment. 

   o  End-Entity Certificate Matching: The transport receiver or
transport sender is configured with information necessary to match the
end-entity certificates of its authorized peers (which can be
self-signed).  Implementations MUST support certificate fingerprints in
section 4.2.3 and MAY allow other formats for end-entity certificates
such as a DER encoded certificate.  This method provides an alternative
to a PKI that is simpler to deploy and still maintains a reasonable
level of security. 

Both transport receiver and transport sender implementations MUST
provide a means to generate a key pair and self-signed certificate in
the case that a key pair and certificate are not available through
another mechanism.

4.2.2  Certificate Fingerprints

Both client and server implementations MUST make the certificate
fingerprint for their certificates available through a management
interface.  

The mechanism to generate a fingerprint is to take the hash of the
certificate using a cryptographically strong algorithm and convert the
result into colon separated, hexadecimal bytes, each represented by 2
uppercase ASCII characters.  When a fingerprint value is displayed or
configured the fingerprint is prepended with an ASCII label identifying
the hash function followed by a colon.  Implementations MUST support
SHA-1 as the hash algorithm and use the ASCII label "SHA1" to identify
the SHA-1 algorithm.  The length of a SHA-1 hash is 20 bytes and the
length of the corresponding fingerprint string is 64 characters. An
example certificate fingerprint is:

	SHA1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D

During validation the hash is extracted from the fingerprint and
compared against the hash calculated over the received certificate.  

[sections skipped]

5. Security Policies

Different environments have different security requirements and
therefore would deploy different security policies.  This section
provides discusses some of the security policies that may be implemented
by syslog transport receivers and syslog transport senders.  The
security policies describe the requirements for authentication,
credential validation and authorization.  The list of policies in this
section is not exhaustive and other policies may be implemented.  

5.1 Recommended Security Policy

The recommended security policy provides protection against the threats
in section 2.  This policy requires authentication, certificate
validation and authorization of both the syslog transport sender and
syslog transport receiver.   If there is a failure in the
authentication, certificate validation or authorization then the
connection is closed.  

Authorization requires the capability to authorize individual hosts as
transport receivers and transport senders.  When end-entity certificate
matching is used, authentication and certificate validation are
sufficient to authorize and entity.  When certificate path validation
MUST support the following authorization mechanisms:

	o Host-name-based authorization where the host name of the
authorized peer is compared against the subject fields in the
certificate.  For the purpose of interoperability, implementations MUST
support matching the host name against a SubjectAltName field with a
type of dNSName and SHOULD support checking hostname against the Common
Name portion of the Subject Distinguished Name.  Matching for
certificate credentials is performed using the matching rules specified
by [3].  If more than one host name identity is present in the
certificate a match in any one of the set is considered acceptable.
Implementations also MAY support wildcards to match a range of values.
For example, names to be matched against a certificate may contain the
wildcard character * which is considered to match any single domain name
component or component fragment.  E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com.  Wildcards
make it possible to deploy trust-root-based authorization where all
credentials issued by a particular CA trust root are authorized.

	o IP-address-based authorization where the IP address configured
for the authorized peer is compared against the subject fields in the
certificate.  Implementations MUST support matching the IP address
against a SubjectAltName field of type iPAddress and MAY support
checking the configured IP address against the Common Name portion of
the Subject Distinguished Name.  Matching for certificate credentials is
performed using the matching rules specified by [3].  If more than one
IP Address identity is present in the certificate a match in any one of
the set is considered acceptable.

Implementations MAY also support authorization based on other
attributes.  For example, the authorization of a device Serial Number
against the SerialNumber portion of the Subject Distinguished Name or
restrictions on the depth of a certificate chain.  

Implementations MUST support this policy and it is recommended that this
be the default policy.  

5.2  Liberal Validation of a Syslog Transport Sender

In some environments, the authenticity of syslog data is not important
or it is verifiable by other means, so transport receivers may accept
data from any transport sender.  To achieve this, the transport receiver
performs authentication and certificate consistency checks and forgoes
the validation of the certificate chain and authorization.   In this
case, the transport receiver is authorized, however this policy does not
protect against the threat of transport sender masquerade described in
Section 2.  The use of this policy is generally not recommended for this
reason.   If this policy is used, the transport receiver SHOULD record
the end-entity certificate for the purpose of correlating it with the
sent data. 

5.3 Liberal Validation of a Syslog Transport Receiver

In some environments the confidentiality syslog data is not important so
data may be sent to any transport receiver.  To achieve this the
transport sender performs authentication certificate consistency checks
and forgoes validation of the certificate chain and authorization.
While this policy does authorize the transport sender, it does not
protect against the threat of transport receiver masquerade described in
Section 2, leaving the data sent vulnerable to disclosure and
modification.  The use of this policy is generally not recommended for
this reason.  

5.4 Liberal Syslog Transport Receiver and Sender Validation

In environments where security is not a concern at all the transport
receiver and transport sender authenticate each other and perform
certificate consistency checks and may forgo validation of the
certificate chain and authorization.  This policy does not protect
against any of the threats described in section 2 and is therefore not
recommended.  

6. Security Considerations

6.1 Deployment Issues

Section 5 discusses various security policies that may be deployed.  The
only configuration that mitigates the threats described in Section 2 is
the recommended policy defined in section 5.1.  This is the recommended
configuration for deployments.  

If the transport receiver chooses not to fully authenticate, validate
and authorize the transport sender it may receive data from an attacker.
Unless it has another way of authenticating the source of the data, the
data should not be trusted.  This is especially important if the syslog
data is going to be used to detect and react to security incidents.  The
transport receiver may also increase its vulnerability to denial of
service, resource consumption and other attacks if it does not
authenticate the transport sender.  Because of the increased
vulnerability to attack, this type of configuration is not recommended. 

If the transport sender chooses not to fully authenticate, validate and
authorize the syslog transport receiver then it may send data to an
attacker.  This may disclose sensitive data within the log information
that is useful to an attacker resulting in further compromises within
the system.  If a transport sender operates in this mode it should limit
the data it sends to data that is not valuable to an attacker.  In
practice this is very difficult to achieve, so this type of
configuration is not recommended.

Forgoing authentication, validation and/or authorization on both sides
allows for man-in-the-middle, masquerade and other types of attacks that
can completely compromise integrity and confidentiality of the data.
This type of configuration is not recommended.    

6.2  Cipher Suites

   [I think the mandatory to implement algorithm should be defined in
section 4.2 instead of the security considerations section]

_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 26 May 2008 09:18:53 +0200

Joe,

I like this new text.

I am snipping everything below except the one thing that drives a

> the set is considered acceptable.

I know that you asked about the usefulness of IP based authentication
before. I am now at a point where I have actually finished my
implementation and I am "polishing" it. On my agenda is now a as good as
possible *automatic* authentication.

For the client to authorize the server, it is quite easy. There usually
is something like

*.* @@192.0.2.1

In this case, I can take the destination ("192.0.2.1") and verify it
against the server's certificate. Provided we use a common root CA, this
setup is fully automatic. So supporting IPs is quite useful in this
scenario. Please note that operators tend to use IP addresses over
hostnames because of reliability reasons and early startup capability of
the syslogd (before DNS resolutions is available). So this is of
practical relevance.

In case of the server authenticating the client, there is no such
obvious choice. I could use the remote client's IP address (provided by
the transport stack) and verify that it matches the IP address inside
the certificate. However, is this really useful? IMO, this is more or
less a check if the remote cert is signed by a common CA. Something that
may be useful, but does not depend on the client's IP be known.

Do you or somebody else on this list (Tom?) have a clue why it may be
useful to carry out such a check?

Back on the topic of easy but still secure configuration, I could
envision taken the reverse DNS name of the transport sender and checking
that against the identity presented in the certificate. Anyone any
thoughts/comments on this?

Again, all of this assumes a common root CA and certificates signed by
it (not necessarily full PKI, but an "in-house CA").

Thanks,
Rainer

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 26 May 2008 11:34:53 +0200

> compared against the hash calculated over the received certificate.

The text above makes it really easy to implement, as there is no longer
a doubt about what the actual format should look like. Also, adding the
hash algo as first field of the fingerprint cleans up a lot of code.

Rainer

---

From: <[email-masked]>
Date: Mon, 26 May 2008 15:28:33 +0300

Rainer Gerhards wrote:

> I know that you asked about the usefulness of IP based
> authentication before. I am now at a point where I have actually
> finished my implementation and I am "polishing" it. On my agenda is
> now a as good as possible *automatic* authentication.
> 
> For the client to authorize the server, it is quite easy.  There
> usually is something like
> 
> *.* @@192.0.2.1
> 
> against the server's certificate. Provided we use a common root CA,
> this setup is fully automatic. So supporting IPs is quite useful in
> this scenario. Please note that operators tend to use IP addresses
> over hostnames because of reliability reasons and early startup
> capability of the syslogd (before DNS resolutions is available). So
> this is of practical relevance.

I agree that in some situations, we don't want to depend on
DNS. However, this is somewhat orthogonal to what the certificate
contains.

AFAIK certificates containing IP addresses are quite rare; host names
are much common.  To support such situation -- while still avoiding
dependency on DNS -- it would be useful if you could configure the IP
address (used for opening the connection) and server name (compared
against the certificate, but not looked up from DNS) separately.

I don't know what that would look like in your configuration file
syntax, but maybe something like

*.* @@192.0.2.1[syslogsrv2.example.com]

> obvious choice. I could use the remote client's IP address (provided
> by the transport stack) and verify that it matches the IP address
> inside the certificate. However, is this really useful? IMO, this is
> more or less a check if the remote cert is signed by a common CA.
> Something that may be useful, but does not depend on the client's IP
> be known.
>

It doesn't seem very useful to me... I guess you could have a local
"wildcard" or "netmask" saying that only clients from 192.0.2.* are
allowed to connect; if your certificates contain IP addresses,
presumably you'd use the address in the certificate (and not the
transport) for that check. (But as I said, certificates containing
IP addresses are not common.)

> envision taken the reverse DNS name of the transport sender and
> checking that against the identity presented in the
> certificate. Anyone any thoughts/comments on this?

This doesn't seem very useful to me, and AFAIK no such thing
is done in other protocols using TLS/certificates.

Best regards,
Pasi

---

From: Rainer Gerhards <[email-masked]>
Date: Mon, 26 May 2008 14:59:52 +0200

Hi Pasi,

inline...

On Mon, 2008-05-26 at 15:28 +0300, [email-masked] wrote:
> are much common.  

Please keep in mind that my message was related to the question if there
is a use case for using IPs inside a certificate. As I said above, there
is.

> To support such situation -- while still avoiding

rsyslog of course supports this. The actual syntax is:

$ActionSendStreamDriverAuthMode x509/name # soon to be default
$ActionSendStreamDriverPermittedPeer syslogsrv2.example.com
*.* @@192.0.2.1

The $ActionSendStreamDriverPermittedPeer directive can be specified
multiple times, for example when talking to an active/passive cluster
with different identities (or whatever else may come up).

To prevent relying on tcp, one could also add syslogsrv2.example.com
to /etc/hosts, which would also lead to

*.* @@syslogsrv2.example.com

In any case, the goal is to have automatic authentication, and this
works well with a common trusted CA. An "in-house" CA may also issue
certificates with IP addresses.

> IP addresses are not common.)

Even if the certificate has an IP - does that really gain me something?
I think using the certificate's IP doesn't provide me any additional
security in this case.

I think this authentication is not useful and the server really can not
automatically be configured to detect permitted remote clients - except
for wildcard names.

(as a side-note, rsyslog allows a mode where it just checks the validity
of the remote certificate - so a common CA can be used to automatically
authorize a broad range of machines).

> is done in other protocols using TLS/certificates.

Plus, it would again introduce the DNS dependency. So that's probably a
bad idea.

But after this conversation: is there really any use case for IP
addresses in the certificate? I begin to get the feeling that we should
probably remove the text about them - there are ample work-arounds to
achieve the same, mostly better, effect.

Rainer

---

From: <[email-masked]>
Date: Mon, 26 May 2008 16:06:08 +0300

Rainer Gerhards wrote:

> Please keep in mind that my message was related to the question if
> there is a use case for using IPs inside a certificate. As I said
> above, there is.

Ok. Do you think this use case is important enough to keep this
feature (checking IPAddress subjectAltName) as part of the "MUST
implement" baseline?

(Joe's latest text already has other forms of name comparison as
optional: "Implementations MAY also support authorization based on
other attributes.  For example, the authorization of a device Serial
Number against the SerialNumber portion of the Subject Distinguished
Name [...]")

> > To support such situation -- while still avoiding dependency on
> > DNS -- it would be useful if you could configure the IP address
> > (used for opening the connection) and server name (compared

Ok, good to know.

Best regards,
Pasi

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 26 May 2008 15:26:00 +0200

> feature (checking IPAddress subjectAltName) as part of the "MUST

No, I don't think it is a MUST. 

> Number against the SerialNumber portion of the Subject Distinguished

This should take care of it well enough.

Rainer

---

From: Martin Schütte <[email-masked]>
Date: Mon, 26 May 2008 17:00:26 +0200

> the syslogd (before DNS resolutions is available). So this is of

As noted later this will require the IP adresses to be included in the 
x509 certificates. The usual verification against the Common Name 
requires DNS.

> the certificate. However, is this really useful?

I think it is necessary since it is a mutual authentication: the client 
verifies the server, and the server verifies the client.
Each Authentication has two steps: 1. verify the trust path to the cert 
(either by CA signature, having the cert itself configured as a trust 
anchor, or having its fingerprint) and 2. check if the cert matches the 
requesting host (by IP or DNS, by Common Name or subjectAltName).

> IMO, this is more or

> useful to carry out such a check?

Maybe the second step should be configurable (like the first one) since 
it is comes down to policy, but the question is: Do you accept a 
connection from client A if it shows a certificate from client B?

You might want to if you use only one cert for all clients, but if every 
client has its own cert then you might not, because this situation 
indicates a serious misconfiguration or intrusion.

> thoughts/comments on this?

Ack. I am going to do the same.

> it (not necessarily full PKI, but an "in-house CA").

Either that or a collection af all involved certificates.
It should not make a difference if a common CA is the trust anchor or if 
every cert itself is.

-- 
Martin

---

From: "Moehrke, John (GE Healthcare)" <[email-masked]>
Date: Mon, 26 May 2008 18:15:32 -0400

I have said this before, but people continue to go down this path... 

The TLS authentication has already proven that the 'other' side holds
the private key... this is cryptographically secure authentication... 

Adding a check of the IP address or DNS address adds very very little
value, and is not cryptographically secure (unless using Secure DNS). 

Therefore there is little value to adding IP or hostname checking, and
lots of ways it will break (NAT, DHCP, etc).

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Rainer Gerhards
> Sent: Monday, May 26, 2008 2:19 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: Re: [Syslog] Some revised text for syslog TLS
> 
> Joe,
> 
> I like this new text.
> 
> > the Subject Distinguished Name.  Matching for certificate
credentials
> > is
usually
> is something like
this
> obvious choice. I could use the remote client's IP address (provided
by
> envision taken the reverse DNS name of the transport sender and
checking

---

From: "Anton Okmyanskiy (aokmians)" <[email-masked]>
Date: Mon, 26 May 2008 19:23:35 -0400

The bottom line is that when you use a certificate to authenticate the
client, the trusted identity of the client that gets recorded in the
messages must be derived from certificate, not from other source like IP
address or whatever device or DNS says device might be. 

This can be handled by specifying appropriate tags (structured data ID)
for certificate fields and recommending that those are added to the
message (or updated) by the receiver if certificate-based authenticate
is used. 

This would prevent the case of some client using legitimate (but stolen)
certificate, and then indicating identity of another device in the
message itself. If such behavior were allowed, then when certificate is
stolen (but not yet put on certificate revocation list), this would
extend the security threat to a wider scope of issues because we are
allowing one device to masquerade as any other device.  

Note, that we need structured data field IDs not only for certificate
Common Name (CN), but also for fields such as fingerprint.  When one
certificate is revoked and a new one issues, I believe the new one can
have the same common name.  In that case, if the receiver wants to
identify which exact certificate the client used, you need to see the
fingerprint or other similar certificate fields. We had a use-case with
customer where such information was needed with TLS (albeit not in
syslog context). 

Regards,
Anton.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Moehrke, John 
> (GE Healthcare)
> Sent: Monday, May 26, 2008 3:16 PM
> To: Rainer Gerhards; Joseph Salowey (jsalowey); [email-masked]
> The TLS authentication has already proven that the 'other' 
> side holds the private key... this is cryptographically 
> secure authentication... 
> 
> Adding a check of the IP address or DNS address adds very 
> very little value, and is not cryptographically secure 
> (unless using Secure DNS). 
> 
> Therefore there is little value to adding IP or hostname 
> checking, and lots of ways it will break (NAT, DHCP, etc).
> 
> John
> 
> > > IP Address identity is present in the certificate a match 
> in any one
> > of
> authentication 
> > implementation and I am "polishing" it. On my agenda is now 
> a as good
> as
> > hostnames because of reliability reasons and early startup 
> capability
> of

---

From: <[email-masked]>
Date: Tue, 27 May 2008 08:51:28 +0300

Anton,

If you want to work on specifying such structured data fields,
that's fine (I agree that they could useful in many situations);
but it's way too late to add anything this big to the 
syslog-transport-tls draft. So this would be a separate document.

Best regards,
Pasi

> From: Anton Okmyanskiy (aokmians)
> Sent: 27 May, 2008 02:24
> To: Moehrke, John (GE Healthcare); Rainer Gerhards; Joseph 
> Salowey (jsalowey); [email-masked]
> The bottom line is that when you use a certificate to authenticate
> the client, the trusted identity of the client that gets recorded in
> the messages must be derived from certificate, not from other source
> like IP address or whatever device or DNS says device might be.
> 
> This can be handled by specifying appropriate tags (structured data
> ID) for certificate fields and recommending that those are added to
> the message (or updated) by the receiver if certificate-based
> authenticate is used.
> 
> This would prevent the case of some client using legitimate (but
> stolen) certificate, and then indicating identity of another device
> in the message itself. If such behavior were allowed, then when
> certificate is stolen (but not yet put on certificate revocation
> list), this would extend the security threat to a wider scope of
> issues because we are allowing one device to masquerade as any other
> device.
> 
> Note, that we need structured data field IDs not only for
> certificate Common Name (CN), but also for fields such as
> fingerprint.  When one certificate is revoked and a new one issues,
> I believe the new one can have the same common name.  In that case,
> if the receiver wants to identify which exact certificate the client
> used, you need to see the fingerprint or other similar certificate
> fields. We had a use-case with customer where such information was
> needed with TLS (albeit not in syslog context).
> 
> Regards,
> Anton.
> 
> 
> 
> > > > for the authorized peer is compared against the subject 
> fields in
> > the
> > > > checking the configured IP address against the Common 
> Name portion
> > of
> > > > performed using the matching rules specified by [3].  
> If more than
> > one
> > > less a check if the remote cert is signed by a common CA. 
> Something
> > that

---

From: "tom.petch" <[email-masked]>
Date: Tue, 27 May 2008 18:05:58 +0200

Going back to the first question...

Tom Petch

----- Original Message -----
From: "Rainer Gerhards" <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>; <[email-masked]>
Sent: Monday, May 26, 2008 9:18 AM
Subject: Re: [Syslog] Some revised text for syslog TLS

> For the client to authorize the server, it is quite easy. There usually

You have lost me here.  Suppose I am a server and I want to check that syslog
only comes from someone I trust so I will configure an identifier in the server
and want security credentials to authenticate an assertion of that identity.
The IP address is the identity, and the certificate the security credential.

Or the host name is the identity and the certificate the security credential.

Or the MAC address is the identity and the certificate the security credential.

I do not see a difference (except that some identities are commoner than others
as Pasi points out).

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Tue, 27 May 2008 18:15:28 +0200

Joe

Looks good.  Once we have sorted out the technicalities eg fingerprints and
iPAddress, you might consider some polishing of the text, in two regards.

In places, I have a sense of a security expert (which you are) talking to a
security expert (which I am not) and think the text needs clarifying. eg "This
consists validating proof of possession of the private key corresponding to the
public key in the certificate".  If this sentence were absent, I would not have
noticed it; being there, I stop and think, what is it telling me, am I missing
something?

Or "Certificate path validation: the client is configured with one or  more
trust anchors"; ditto, if that were absent, I would not have noticed.

And, as in the first sentence I quote, there seem to be some words or phrases
missing; as I say, let's sort out any technical changes and then I will revisit
the wording

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Tue, 27 May 2008 18:06:45 +0200

----- Original Message ----- 
From: "Rainer Gerhards" <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 26, 2008 3:26 PM
Subject: Re: [Syslog] Some revised text for syslog TLS

> No, I don't think it is a MUST. 

But I would like it to be a SHOULD.

Tom Petch

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 28 May 2008 10:35:55 +0200

Tom,

inline...

<snip>

> > useful to carry out such a check? (EDIT: check of IP address)
> 

What is common is a big point. I think ipAddress inside certificates is
quite uncommon, so this may be a good indication that it doesn't justify
a MUST.

I have also thought about when this may be used at all. IMHO, this makes
only sense if the transport sender uses a proxy or is behind NAT. Using
a proxy for syslog senders is extremely uncommon. Being behind NAT is
uncommon (usually, syslog is not transmitted to the public Internet).
The remaining threat I see is that someone on the same local network
poisons ARP with a spoofed IP address and they tries to fool the syslog
server in listening to it. While possible, I think this is also quite
remote (but remote is not a good argument when it comes to security, I
know). What matters more is that this attack will NOT work if the
subject's name is checked against the certificate.

So what is the extra benefit of authorizing based on IP address? What is
the advantage of it? Is that so important that every syslog application
implementing MUST support it? I am even in doubt if if justifies a
SHOULD. To me it looks MAY would be sufficient, and this is covered by
the text. So I think the whole paragraph on ipAddress authentication can
simply be removed.

As a side-note, authentication based on IP addresses is even
problematic. In my experience IP ranges are more likely to change than
names, so sticking with names reduces the administrative cost when a
change is needed.

Rainer

---

From: [email-masked]
Date: Wed, 28 May 2008 09:23:43 -0400

The new text looks close.  I agree with Rainer that the MUST on checking 
IP Address should drop to a MAY, or better yet be removed entirely.   It 
could be subsumed within the general ability to check various content 
fields within the certificate.  I find that CN is much more useful.  A MAY 
for CN checking makes much more sense to me.

I think that this is just a leftover from someone's particular use case, 
rather than based on a real security analysis.  Passing the certificate 
test means that both sides have demonstrated that they know their own 
private keys.  That is the good mandatory check.  If either side does not 
know their own private key you have strong evidence that they are not who 
they claim to be.  The real system will always know its own private keys. 
IP address is just a special case.

Passing the certificate test does not mean 100% certainty for 
authentication.  There is always the risk that the machine has not 
protected its private keys.  They can be stolen and the machine can be 
penetrated.  Perhaps someone could explain why the presence of the IP 
Address in the certificate should automatically imply that security has 
been compromised.  Plus why does matching IP address in certificate and 
network eliminate that implication.  I can think of special use cases 
where this is the case, but by making it a MUST the RFC makes this is a 
global statement.

In practice, if the MUST goes through I'll just make formal policy 
recommendations that healthcare never include IP Address in certificates. 
This is a reasonable recommendation anyhow.  In the present world of NAT, 
DHCP, IPv6 negotiation, mobile machines, etc. the IP address is rather 
unstable.  It doesn't make sense to put it into certificates.  If really 
pressed, I might mention that there is also a minor bug in the syslog-tls 
RFC.

Kind Regards,

Robert Horn | Agfa HealthCare
Research Scientist | HE/Technology Office
T  +1 978 897 4860

Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 
07660-2199, United States
http://www.agfa.com/healthcare/
Click on link to read important disclaimer: 
http://www.agfa.com/healthcare/maildisclaimer
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: "tom.petch" <[email-masked]>
Date: Wed, 28 May 2008 15:51:24 +0200

Inline
Tom Petch

----- Original Message -----
From: "Rainer Gerhards" <[email-masked]>
To: "tom.petch" <[email-masked]>; "Joseph Salowey (jsalowey)"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, May 28, 2008 10:35 AM
Subject: RE: [Syslog] Some revised text for syslog TLS

Tom,

inline...

<snip>

<tp>

I encounter networks where the devices do not have names, in any meaningful
manner (perhaps just a default sysName left in by the manufacturer).  Boxes are
identified by address, layer 2 - MAC - or layer 3 - IP.  What I am resisting is
the need to allocate and maintain a namespace where none exists at present.

This use of IP address is independent of what appears in the IP header of the
packet; here it is serving as an identity for the box not as something to put in
the source field of the IP header. In theory, if the IP address of the device
changed, then you could keep the old address as an identity but I think that
would be too bizarre.

Tom Petch
</tp>

Rainer

---

From: Rainer Gerhards <[email-masked]>
Date: Wed, 28 May 2008 17:50:28 +0200

Tom,

> changed, then you could keep the old address as an identity but I think that

I see your point. I always looked from the security perspective, but
that isn't what you are trying to achieve. It is the need not to start
another new name space... OK.

>From the implementors POV, I think ipAddress will bring in another set
of matching rules (you've probably seen my other message on this topic).
I have seen that, for example, I must support IP range matching. It also
looks like I need to do netmask based matching. Of course, all of this
is not rocket science. It may even be already used in other parts of the
same program. I still wonder if we should really require every
implementation to carry all that additional code just to permit this
scenario which, to be honest, seems to be a quite uncommon case.

May it be a good work-around to simply use the reverse DNS ptr names as
the subject alt name?

Rainer

---

From: <[email-masked]>
Date: Thu, 29 May 2008 03:41:19 +0300

Rainer Gerhards wrote:

> May it be a good work-around to simply use the reverse DNS ptr names
> as the subject alt name?

No, I don't think this would be a good work-around. An implementation
should never compare the result of a PTR lookup against a host name in
the certificate (doing so would give the impression that it's done for
some security reason, but it doesn't seem to provide any security
benefit).

Best regards,
Pasi

---

From: "tom.petch" <[email-masked]>
Date: Thu, 29 May 2008 09:54:07 +0200

----- Original Message -----
From: "Moehrke, John (GE Healthcare)" <[email-masked]>
To: "Rainer Gerhards" <[email-masked]>; "Joseph Salowey (jsalowey)"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, May 27, 2008 12:15 AM
Subject: Re: [Syslog] Some revised text for syslog TLS

> the private key... this is cryptographically secure authentication...

True, but authentication of what? This logic says you might as well use naked
public/private keys, as SSH does.  For me, the point of all the extra hassle of
certificates is that the keys are bound to an identity/identifier so you can
tell, to some degree (depending on what checks the CA has performed) to whom you
are talking.  Then it becomes a question of what identifier to use, CN, MAC,
etc.

At something of a tangent, I see work in RIPE (and the IETF) to use (R)PKI to
secure the routing system so it will become possible to authenticate the
assignee of an IP address.  Not directly applicable, but encouraging both for
the use of PKI and for the acceptability of IP addresses therein.

Tom Petch

---

From: [email-masked]
Date: Thu, 29 May 2008 09:41:43 -0400

[tom-petch]> 
> are talking.  Then it becomes a question of what identifier to use, CN, 
MAC,

You live in a radically different threat-asset environment than healthcare 
I can tell.  In our environment the SSH process would do fine for about 
half the users, and the official root CA approach is appropriate to about 
0% of the users.  The value of using the certificates for all of them is 
software development.  Certificates are a widely supported mechanism in 
most security libraries.  There is no comparable alternative for a 
standard format.  The half of our world that deals with authentication out 
of band can use certificates and ignore all the extraneous infrastructure. 
 Out of band mechanisms are very significant in healthcare.  We have all 
sorts of patient safety issues that must be managed.  For example, any 
hardware change (even just a board swap) can require safety retesting for 
patient contact devices.  Adding machine identification and authentication 
to that process is a low cost addition.  It's much cheaper than building 
up a suitable PKI infrastructure for the smaller sites.

The official root CA approach is a non-starter because in the other half 
of our world where chain of trust does make sense, the usual root CAs 
haven't a clue.  Do you really think that Verisign knows whether that PC 
in my local hospital has been configured for the admitting clerk's desk or 
for the surgical suite?  They do not and they do not want to keep track of 
that information.  There is a completely different chain of trust used in 
hospitals and clinics.  The trusted anchor is part of the hospital and 
clinic organization.  It coordinates with the Bio-med department regarding 
device allocation.  It does know what machines are assigned where and for 
what purposes.

In healthcare you pick a trusted anchor that knows these things.  It will 
not chain outside the healthcare organization.  This organization might be 
rather large when you get into various national health systems, but the 
anchor is within the healthcare system.

R Horn

---

From: Martin Schütte <[email-masked]>
Date: Thu, 29 May 2008 23:33:50 +0200

> against the certificate, but not looked up from DNS) separately.

Having the iPAddress inside the certificate solves this nicely, without 
additional configuration.

> *.* @@192.0.2.1[syslogsrv2.example.com]

One question here: Why is it required to use hostnames only insted of 
the Distinguished Name of the certificate?

---

From: "tom.petch" <[email-masked]>
Date: Fri, 30 May 2008 10:11:01 +0200

Understand.

I too do not see root CAs like Verisign being much involved; rather, a large
enterprise will have its own CA, which makes it easier to use things other than
names.  But I still see them checking that the identity in the certificate is as
expected, rather than just checking that certificate is technically valid.

I recall the issue of 'private' PKI(!) coming up before on this list, and I
recall one use case, raised by Anton, where the box serial number as inserted by
the manufacturer was also inserted into the certificate installed on the box.
(Anton was also a driver for generic certificates).

So I see a use case for checking the identity, as well as circumstances, such as
yours, where it will not be performed.

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Moehrke, John (GE Healthcare)" <[email-masked]>; "Joseph Salowey
(jsalowey)" <[email-masked]>; "Rainer Gerhards" <[email-masked]>;
"syslog" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 29, 2008 3:41 PM
Subject: Re: [Syslog] Some revised text for syslog TLS