Subject: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt

From: [email-masked]
Date: Wed, 7 May 2008 08:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF.

	Title           : TLS Transport Mapping for Syslog
	Author(s)       : M. Fuyou, et al.
	Filename        : draft-ietf-syslog-transport-tls-12.txt
	Pages           : 13
	Date            : 2008-05-07

This document describes the use of Transport Layer Security (TLS) to
provide a secure connection for the transport of syslog messages.
This document describes the security threats to syslog and how TLS
can be used to counter such threats.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 May 2008 15:20:07 -0400

Hi,

We have had a bit of dicussion based on implementations, and I welcome
that input. The notes you made while doing your implementations might
have been based on the -11- draft.

Now that a new draft -12- is available, we encourage you to see if the
comments are still valid. It would be very helpful if comments are
clear about whether they are relevant to -11- or -12-, in case there
is a difference. (Obvously, we would like comments to be about -12-,
but for a short time won't reject implementation comments based on
-11-).

Thanks,
David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
[email-masked]
> Sent: Wednesday, May 07, 2008 11:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt
>

---

From: [email-masked]
Date: Thu, 8 May 2008 11:53:26 -0400

Section 4.2 is better, but it still needs work to separate the policy 
decisions from the protocol definition.  Policy decisions are driven by 
risk analysis of the assets, threats, and environment (among other 
things).  These are not uniform over all uses of syslog.  That makes it 
important to separate the policy from the protocol, in both the 
specifications and in the products.

In the healthcare environment we use TLS to protect many of our 
connections.  This is both an authentication protection and a 
confidentiality protection.  The policy decisions regarding key management 
and verification will be very similar for a healthcare use of syslog. Some 
healthcare sites would reach the same policy decision as is in 4.2, but 
here are three other policy decisions that are also appropriate:

Policy A:
   The clients are provided with their private keys and the public 
certificates for their authorized servers by means of physical media, 
delivered by hand from the security office to the client machine support 
staff.  (The media is often CD-R because it's cheap, easy to create, easy 
to destroy, and easy to use.)  During TLS establishment the clients use 
their assigned private key and the server confirms that the connection is 
from a machine with one of the assigned private keys.  The client confirms 
that the server matches one of the provided public certificates by direct 
matching.  This is similar to the fingerprint method, but not the same. My 
most recent experience was with an installation using this method.  We had 
two hours to install over 100 systems, including the network facilities. 
This can only be done by removing as many installation schedule 
dependencies as possible.  The media method removed the certificate 
management dependencies.

Policy B:
  These client systems require safety and functional certification before 
they are made operational.  This is done by inspection by an acceptance 
team.  The acceptance team has a "CA on a laptop".  After accepting safety 
and function, they establish a direct isolated physical connection between 
the client and the laptop.  Then using standard key management tools, the 
client generates a private key and has the corresponding public 
certificate generated and signed by the laptop.  The client is also 
provided with a public certificate for the CA that must sign the certs for 
all incoming connections.

During a connection setup the client confirms that the server key has been 
signed by that CA.  This is similar to a trusted anchor, but not the same. 
 There is no chain of trust permitted.  The key must have been directly 
signed by the CA.  During connection setup the server confirms that the 
client cert was signed by the "CA on a laptop".  Again, no chain of trust 
is permitted.  This policy is incorporating the extra aspect of "has been 
inspected by the acceptance team" as part of the authentication meaning. 
They decided on a policy-risk basis that there was not a need to confirm 
re-inspection, but the "CA on a laptop" did have a revocation server that 
was kept available to the servers, so that the acceptance team could 
revoke at will.

Policy C:
  This system was for a server that accepted connections from several 
independent organizations.  Each organization managed certificates 
differently, but ensured that the organization-CA had signed all certs 
used for external communications by that organization.  All of the client 
machines were provided with the certs for the shared servers (by a method 
similar to the fingerprint method).  During TLS connection the clients 
confirmed that the server cert matched one of the certs on their list. The 
server confirmed that the client cert had been signed by the CA 
responsible for that IP subnet.  The server was configured with a list of 
organization CA certs and their corresponding IP subnets.

I do not expect any single policy choice to be appropriate for all syslog 
uses.  I think it will be better to encourage a separation of function in 
products.  There is more likely to be a commonality of configuration needs 
for all users of TLS on a particular system than to find a commonality of 
needs for all users of syslog.   The policy decisions implicit in section 
4.2 make good sense for many uses.  They are not a complete set.  So a 
phrasing that explains the kinds of maintenance and verification needs 
that are likely is more appropriate.  The mandatory verifications can be 
separated from the key management system and kept as part of the protocol 
definition.  The policy decisions should be left as important examples.

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: "Rainer Gerhards" <[email-masked]>
Date: Fri, 9 May 2008 10:36:22 +0200

Hi all,

I agree to Robert, policy decisions need to be separated. I CC Pasi
because my comment is directly related to IESG requirements, which IMHO
cannot be delivered by *any* syslog TLS document without compromise
[comments directly related to IESG are somewhat later, I need to level
ground first].

Let me tell the story from my implementor's POV. This is necessarily
tied to rsyslog, but I still think there is a lot of general truth in
it. So I consider it useful as an example.

I took some time yesterday to include the rules laid out in 4.2 into
rsyslog design. I quickly came to the conclusion that 4.2. is talking
about at least two things:

a) low-level handshake validation 
b) access control

In a) we deal with the session setup. Here, I see certificate exchange
and basic certificate validation (for example checking the validity
dates). In my current POV, this phase ends when the remote peer can
positively be identified.

Once we have positive identification, b) kicks in. In that phase, we
need to check (via ACLs) if the remote peer is permitted to talk to us
(or we are permitted to talk to it). Please note that from an
architectural POV, this can be abstracted to a higher layer (and in
rsyslog it probably will). For that layer, it is quite irrelevant if the
remote peer's identity was obtained via a certificate (in the case of
transport-tls), a simple reverse lookup (UDP syslog), SASL (RFC 3195) or
whatever. What matters is that the ACL engine got a trusted identify
from the transport layer and verifies that identity [level of trust
varies, obviously]. Most policy decisions happen on that level.

There is some grayish between a) and b). For example, I can envision
that if there is a syslog.conf rule (forward everything to
server.example.net)

*.* @@server.example.net

The certificate name check for server.example.net (using dNSName
extension) could probably be part of a) - others may think it is part of
b).

Also, even doing a) places some burden onto the system, like the need to
have trust anchors configured in order to do the validation. This hints
at at least another sub-layer.

I think it would be useful to spell out these different entities in the
draft.

Coming back to policy decisions, one must keep in mind that the IESG
explicitly asked for those inside the document. This was done based on
the -correct- assumption that today's Internet is no longer a friendly
place. So the IESG would like to see a default policy implemented that
provides at least a minimum acceptable security standard. Unfortunately,
this is not easy to do in the world of syslog. For the home users, we
cannot rely on any ability to configure something. For the enterprise
folks, we need to have defaults that do not get into their way of doing
things [aka "can be easily turned off"]. There is obviously much in
between these poles, so it largely depends on the use case. I have begun
a wiki page with use cases and hope people will contribute to it. It
could lead us to a much better understanding of the needs (and the
design decisions that need to be made to deliver these). It is available
at

http://wiki.rsyslog.com/index.php/TLS_for_syslog_use_cases

After close consideration, I think the draft currently fails on
addressing the two use cases define above properly. Partly it fails
because it is not possible under the current IESG requirement to be safe
by default. We cannot be fully safe by default without configuration, so
whatever we specify will fail for the home user.

A compromise may be to provide "good enough" security in the default
policy. I see two ways of doing that: one is to NOT address the
Masquerade and Modification threats in the default policy, just the
Disclosure threat. That leads us to unauthenticated syslog being the
default (contrary to what is currently implemented) [Disclosure is
addressed in this scenario as long as the client configs are not
compromised, which I find sufficiently enough - someone who can
compromise the client config can find other ways to get hold of the
syslog message content].

An alternative is to use the way HTTPS works: we only authenticate the
server. To authenticate, we need to have trusted certificate inside the
server. As we can see in HTTPS, this doesn't really require PKI. It is
sufficient to have the server cert singed by one of few globally trusted
CAs and have this root certificates distributed with all client
installations as part of their setup procedure. This is quite doable. In
that scenario, a client can verify a server's identity and the above
sample (*.* @server.example.net) could be verified with sufficient
trust. The client, however, is still not authenticated. However, the
threats we intended to address are almost all addressed, except for the
access control issue which is defined as part of the Masquerade threat
(which I think is even a different beast and deserves its own threat
definition now that I think about it). In short we just have an access
control issue in that scenario. Nothing else.
 
The problem, however, is that the server still needs a certificate and
now even one that, for a home user, is prohibitively expensive. The end
result will be that people turn off TLS, because they neither know how
to obtain the certificate nor are willing to trade in a weekend vacation
for a certificate ;) In the end result, even that mode will be less
useful than anonymous authentication.

The fingerprint idea is probably a smart solution to the problem. It
depends on the ability to auto-generate a certificate [I expressed that
I don't like that idea yesterday, but my thinking has evolved ;)] OR to
ship every device/syslogd with a unique certificate. In this case, only
minimal interaction is required. The idea obviously is like with SSH: if
the remote peer is unknown, the user is queried if the connection
request is permitted and if the certificate should be accepted in the
future. If so, it is added permanently to the valid certificate store
and used in the future to authenticate requests from the same peer. This
limits the security weakness to the first session. HOWEVER, the problem
with syslog is that the user typically cannot be prompted when the
initial connection happens (everything is background activity). So the
request must actually be logged and an interface be developed that
provides for user notification and the ability to authorize the request.

This requires some kind of "unapproved certificate store" plus a
management interface for it. Well done, this may indeed enable a home
user to gain protection from all three threats without even knowing what
he really does. It "just" requires some care in approving new
fingerprints, but that's a general problem with human nature that we may
tackle by good user interface desig but can't solve from a protocol
point of view.

The bad thing is that it requires much more change to existing syslogd
technology. That, I fear, reduces acceptance rate. Keep in mind that we
already have a technically good solution (RFC 3195) which miserably
failed in practice due to the fact it required too much change.

If I look at *nix implementations, syslogd implementers are probably
tempted to "just" log a message telling "could not accept remote
connection due to invalid fingerprint xx:xx:..." and leave it to the
user to add it to syslog.conf. However, I fear that for most home setups
even that would be too much. So in the end effect, in order to avoid
user hassle, most vendors would probably default back to UDP syslog and
enable TLS only on user request.

From my practical perspective this sounds even reasonable (given the
needs and imperfections of the real world...). If that assessment is
true, we would probably be better off by using anonymous TLS as the
default policy, with the next priority on fingerprint authentication as
laid out above. A single big switch could change between these two in
actual implementations. Those users that "just want to get it running"
would never find that switch but still be somewhat protected while the
(little) more technically aware can turn it to fingerprint
authentication and then will hopefully be able to do the remaining few
configuration steps. Another policy is the certificate chain based
policy, where using public CAs would make sense to me.

To wrap it up: 

1. I propose to lower the default level of security 
   for the reasons given.
   My humble view is that lower default security will result in higher
   overall security.

2. We should split authentication policies from the protocol itself
   ... just as suggested by Robert and John. We should define a core 
   set of policies (I think I described the most relevant simple 
   cases above, Robert described some complex ones) and leave it
   others to define additional policies based on their demand.

Policies should go either into their own section OR into their own
documents. I have a strong favor of putting them into their own
documents if that enables us to finally finish/publish -transport-tls
and the new syslog RFC series. If that is not an option, I'd prefer to
spend some more work on -transport-tls, even if it delays things
further, instead of producing something that does not meet the needs
found in practice.

Rainer

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Thursday, May 08, 2008 5:53 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: Re: [Syslog] I-D
Action:draft-ietf-syslog-transport-tls-12.txt
> matching.  This is similar to the fingerprint method, but not the
same.
> My

---

From: "Moehrke, John (GE Healthcare)" <[email-masked]>
Date: Fri, 9 May 2008 12:18:29 -0400

Could someone please point me at the mentioned IESG requirement to
include policy decisions? This is a very unusual position. And as your
own assessment shows is something that simply will not scale.

For example, there are healthcare systems installed on military ships
where all network wiring is inside compressed nitrogen casings with
sensors. This is clearly a sensitive environment, but they have already
managed many of the risks. 

John

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Rainer Gerhards
> Sent: Friday, May 09, 2008 3:36 AM
> To: [email-masked]; Joseph Salowey (jsalowey); [email-masked]

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 9 May 2008 18:36:22 +0200

John,

I need to find it inside the mailing list archive. If I remember, it
came up during rechartering (2? 3? Years ago). It was along the lines
that a secure transport AND secure default for that transport are
required. This is the primary reason that -syslog-protocol and
-transport-udp can not advance to RFC before -transport-tls is done.

Rainer

> From: Moehrke, John (GE Healthcare) [mailto:[email-masked]]
> Sent: Friday, May 09, 2008 6:18 PM
> To: Rainer Gerhards; [email-masked]; Joseph Salowey (jsalowey);
> [email-masked]
> Subject: RE: [Syslog] I-D

---

From: "David Harrington" <[email-masked]>
Date: Fri, 9 May 2008 15:37:52 -0400

Hi,

Acting as co-chair, I request that everybody please read BCP61, found
in RFC 3365 - "Strong Security Requirements for Internet Engineering
Task Force Standard Protocols". It's short. ;-)

If the IESG required strong security features for syslog, then the
IESG was probably enforcing the IETF consensus documented in this RFC.
This BCP has not been updated or obsoleted to my knowledge. BUT -  the
IESG **may** be working off a newer consensus, so we may need to see
what was said, or get input from our responsible AD.

I don't think it says the security features must be enabled by
default, or that policy decisions should be included in the protocool
specification. It reports IETF rough consensus that "all IETF
protocols should operate securely". However, RFC 3365 is also clear
that "MUST is for implementers", not users - "it is completely
reasonable for security features to be an option that the end user of
the protocol may choose to disable."

RFC 3365 does not use the word default, nor the word enabled, and in
my reading of the document, I see nothing that states that strong
security MUST be enabled by default.

But please continue checking what was said by the IESG when we
rechartered (or whenever it was).

David Harrington
[email-masked]
[email-masked]
[email-masked]

> [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> Sent: Friday, May 09, 2008 12:36 PM
> To: Moehrke, John (GE Healthcare); [email-masked]; 
> Joseph Salowey (jsalowey); [email-masked]
> > > because my comment is directly related to IESG requirements,
which
> > IMHO

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 9 May 2008 22:48:50 +0200

I went through the mailing list archive, but I did not find one single
message wrapping it up. Maybe this here comes close:

http://www.ietf.org/mail-archive/web/syslog/current/msg00772.html

Getting the whole thing together requires substantial work. I personally
do not think this is useful (given what you have posted). If in doubt,
we should probably better ask for advise from our current AD.

Rainer 

> From: David Harrington [mailto:[email-masked]] 
> Sent: Friday, May 09, 2008 9:38 PM
> To: Rainer Gerhards; 'Moehrke, John (GE Healthcare)'; 
> [email-masked]; 'Joseph Salowey (jsalowey)'; [email-masked]

---

From: Martin Schütte <[email-masked]>
Date: Sat, 10 May 2008 17:33:23 +0000

>    The transport sender (TLS client) has three different options for
>    authenticating and authorizing the transport receiver (TLS server).

I do not know if this has been discussed previously, but what is your 
opinion on lower requirements in order to get transport-tls supported by 
embedded devices, i.e. switches and printers?

Scenario:
I could imagine a printer (as the client) having a self-signed 
certificate and no ability to authenticate the server's certificate.
As long as the server has a copy of the client's certificate and can 
verify it, a secure transport is possible. As an admin I would rather 
configure this one-way authentication and get a TLS-enabled device than 
having to fall back to UDP.
Should this be an allowed scenario to be covered by tls-transport?

Scenario2:
Say the same printer with its self-signed cert is configurable with a 
CA-cert that enables it to authenticate the server (but maybe without 
checking the certificate's CN/dNSName/IP).
That would allow a reasonably secure setup. -- Should this be an allowed 
scenario to be covered by tls-transport?
In my opinion it should be, thus I would like to keep the requirements 
on authentication rules as simple as possible.

-- 
Martin

---

From: Martin Schütte <[email-masked]>
Date: Sat, 10 May 2008 17:33:21 +0000

>    o  Certificate fingerprints: For each transport receiver, the client
>       is configured with a fingerprint of the server's certificate
>       (which can be self-signed).  This option MUST be supported.

Am I the only one who finds this whole fingerprint option completely
unnecessary?
Is this practice actually used somewhere? I have not heard about this
before and get the impression it is only a bad substitute for copying 
the peer's certificate.

-- 
Martin

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 11 May 2008 20:39:35 -0700

Hi Rainer,

Comments inline below: 

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Friday, May 09, 2008 1:36 AM
> Cc: [email-masked]
> I agree to Robert, policy decisions need to be separated. I 
> CC Pasi because my comment is directly related to IESG 
> requirements, which IMHO cannot be delivered by *any* syslog 
> TLS document without compromise [comments directly related to 
> IESG are somewhat later, I need to level ground first].
> 
> Let me tell the story from my implementor's POV. This is 
> necessarily tied to rsyslog, but I still think there is a lot 
> of general truth in it. So I consider it useful as an example.
> 
> I took some time yesterday to include the rules laid out in 
> 4.2 into rsyslog design. I quickly came to the conclusion 
> that 4.2. is talking about at least two things:
> 
[Joe] It is possible for the document to separate out
authentication/cert validation from authorization.  I would note that
there tends to be a lot of linkages between the two so this will tend
increase the amount of text needed.  If the working group wants to do
this I can work on it. 

> In a) we deal with the session setup. Here, I see certificate 
> exchange and basic certificate validation (for example 
> checking the validity dates). In my current POV, this phase 
> ends when the remote peer can positively be identified.
> 
> Once we have positive identification, b) kicks in. In that 
> phase, we need to check (via ACLs) if the remote peer is 
> permitted to talk to us (or we are permitted to talk to it). 
> Please note that from an architectural POV, this can be 
> abstracted to a higher layer (and in rsyslog it probably 
> will). For that layer, it is quite irrelevant if the remote 
> peer's identity was obtained via a certificate (in the case 
> of transport-tls), a simple reverse lookup (UDP syslog), SASL 
> (RFC 3195) or whatever. What matters is that the ACL engine 
> got a trusted identify from the transport layer and verifies 
> that identity [level of trust varies, obviously]. Most policy 
> decisions happen on that level.
> 
> There is some grayish between a) and b). For example, I can 
> envision that if there is a syslog.conf rule (forward everything to
> server.example.net)
> 
> *.* @@server.example.net
> 
> extension) could probably be part of a) - others may think it 
> is part of b).
> 
> Also, even doing a) places some burden onto the system, like 
> the need to have trust anchors configured in order to do the 
> validation. This hints at at least another sub-layer.
> 
> I think it would be useful to spell out these different 
> entities in the draft.
> 
[Joe] What do you mean by entities.  We can define two separate
processes that need to happen, but I don't think we want to specify how
an implementor must build this. 

> 
> Coming back to policy decisions, one must keep in mind that 
> the IESG explicitly asked for those inside the document. This 
> was done based on the -correct- assumption that today's 
> Internet is no longer a friendly place. So the IESG would 
> like to see a default policy implemented that provides at 
> least a minimum acceptable security standard. 

[Joe] I believe this is part of the goal.  I think there is also the
desire that implementations support some basic level of policy that
allows interoperability.  Implementations can support other policies,
deployers can deploy other policies. 

> Unfortunately, 
> this is not easy to do in the world of syslog. For the home 
> users, we cannot rely on any ability to configure something. 
> For the enterprise folks, we need to have defaults that do 
> not get into their way of doing things [aka "can be easily 
> turned off"]. There is obviously much in between these poles, 
> so it largely depends on the use case. I have begun a wiki 
> page with use cases and hope people will contribute to it. It 
> could lead us to a much better understanding of the needs 
> (and the design decisions that need to be made to deliver 
> these). It is available at
> 
> After close consideration, I think the draft currently fails 
> on addressing the two use cases define above properly. Partly 
> it fails because it is not possible under the current IESG 
> requirement to be safe by default. We cannot be fully safe by 
> default without configuration, so whatever we specify will 
> fail for the home user.
> 
> A compromise may be to provide "good enough" security in the 
> default policy. I see two ways of doing that: one is to NOT 
> address the Masquerade and Modification threats in the 
> default policy, just the Disclosure threat. That leads us to 
> unauthenticated syslog being the default (contrary to what is 
> currently implemented) [Disclosure is addressed in this 
> scenario as long as the client configs are not compromised, 
> which I find sufficiently enough - someone who can compromise 
> the client config can find other ways to get hold of the 
> syslog message content].
> 
[Joe] If you don't address the relevant threats I'm not sure you can
call security "good enough".

> An alternative is to use the way HTTPS works: we only 
> authenticate the server. To authenticate, we need to have 
> trusted certificate inside the server. As we can see in 
> HTTPS, this doesn't really require PKI. It is sufficient to 
> have the server cert singed by one of few globally trusted 
> CAs and have this root certificates distributed with all 
> client installations as part of their setup procedure. This 
> is quite doable. In that scenario, a client can verify a 
> server's identity and the above sample (*.* 
> @server.example.net) could be verified with sufficient trust. 
> The client, however, is still not authenticated. However, the 
> threats we intended to address are almost all addressed, 
> except for the access control issue which is defined as part 
> of the Masquerade threat (which I think is even a different 
> beast and deserves its own threat definition now that I think 
> about it). In short we just have an access control issue in 
> that scenario. Nothing else.
> 
[Joe] I think the threat model in the document describes masquerade of
the client.  Perhaps access control is not the only way to deal with
this, perhaps just being able to associate the authenticated identity
with the messages is enough, I don't know at this point. 

> The problem, however, is that the server still needs a 
> certificate and now even one that, for a home user, is 
> prohibitively expensive. The end result will be that people 
> turn off TLS, because they neither know how to obtain the 
> certificate nor are willing to trade in a weekend vacation 
> for a certificate ;) In the end result, even that mode will 
> be less useful than anonymous authentication.
> 
> The fingerprint idea is probably a smart solution to the 
> problem. It depends on the ability to auto-generate a 
> certificate [I expressed that I don't like that idea 
> yesterday, but my thinking has evolved ;)] OR to ship every 
> device/syslogd with a unique certificate. In this case, only 
> minimal interaction is required. The idea obviously is like 
> with SSH: if the remote peer is unknown, the user is queried 
> if the connection request is permitted and if the certificate 
> should be accepted in the future. If so, it is added 
> permanently to the valid certificate store and used in the 
> future to authenticate requests from the same peer. This 
> limits the security weakness to the first session. HOWEVER, 
> the problem with syslog is that the user typically cannot be 
> prompted when the initial connection happens (everything is 
> background activity). So the request must actually be logged 
> and an interface be developed that provides for user 
> notification and the ability to authorize the request.
> 
> This requires some kind of "unapproved certificate store" 
> plus a management interface for it. Well done, this may 
> indeed enable a home user to gain protection from all three 
> threats without even knowing what he really does. It "just" 
> requires some care in approving new fingerprints, but that's 
> a general problem with human nature that we may tackle by 
> good user interface desig but can't solve from a protocol 
> point of view.
> 
> The bad thing is that it requires much more change to 
> existing syslogd technology. That, I fear, reduces acceptance 
> rate. Keep in mind that we already have a technically good 
> solution (RFC 3195) which miserably failed in practice due to 
> the fact it required too much change.
> 
> If I look at *nix implementations, syslogd implementers are 
> probably tempted to "just" log a message telling "could not 
> accept remote connection due to invalid fingerprint 
> xx:xx:..." and leave it to the user to add it to syslog.conf. 
> However, I fear that for most home setups even that would be 
> too much. So in the end effect, in order to avoid user 
> hassle, most vendors would probably default back to UDP 
> syslog and enable TLS only on user request.
> 
> From my practical perspective this sounds even reasonable 
> (given the needs and imperfections of the real world...). If 
> that assessment is true, we would probably be better off by 
> using anonymous TLS as the default policy, with the next 
> priority on fingerprint authentication as laid out above. A 
> single big switch could change between these two in actual 
> implementations. Those users that "just want to get it running"
> authentication and then will hopefully be able to do the 
> remaining few configuration steps. Another policy is the 
> certificate chain based policy, where using public CAs would 
> make sense to me.
> 
> To wrap it up: 
> 
[Joe] I'm not convinced of this.  If you use TLS without authentication
and authorization you don't really gain any security benefit from it, it
is pretty much the equivalent of not running security.  It might be
reasonable to relax the requirement on being able to do access control
on the server, but I think the threat section would need to discuss
this. 

>    others to define additional policies based on their demand.
[Joe] We can split the policies, but I don't it will necessarily be as
clean as one might hope.  I believe the document does have to specify a
minimum set of policies that can 

A) enable interoperable deployment 
B) provide mitigation against the listed threats

Additional policies can be supported and defined (in this document or a
separate one). 

> Policies should go either into their own section OR into 
> their own documents. I have a strong favor of putting them 
> into their own documents if that enables us to finally 
> finish/publish -transport-tls and the new syslog RFC series. 
> If that is not an option, I'd prefer to spend some more work 
> on -transport-tls, even if it delays things further, instead 
> of producing something that does not meet the needs found in practice.
> 

> > confidentiality protection.  The policy decisions regarding key 
> > management and verification will be very similar for a 
> healthcare use 
> > of syslog.
> > Some
> > delivered by hand from the security office to the client machine 
> > support staff.  (The media is often CD-R because it's 
> cheap, easy to 
> > create, easy to destroy, and easy to use.)  During TLS 
> establishment 
> > the clients
> use
> > their assigned private key and the server confirms that the 
> connection 
> > is from a machine with one of the assigned private keys.  
> The client 
> > confirms that the server matches one of the provided public 
> > certificates by direct matching.  This is similar to the 
> fingerprint 
> > method, but not the
> same.
> > My
> > most recent experience was with an installation using this 
> method.  We 
> > had two hours to install over 100 systems, including the network 
> > facilities.
> >   These client systems require safety and functional certification 
> > before they are made operational.  This is done by inspection by an
> acceptance
> > team.  The acceptance team has a "CA on a laptop".  After accepting 
> > safety and function, they establish a direct isolated physical 
> > connection between the client and the laptop.  Then using 
> standard key 
> > management tools, the client generates a private key and has the 
> > corresponding public certificate generated and signed by 
> the laptop.  
> > The client is also provided with a public certificate for 
> the CA that 
> > must sign the certs for all incoming connections.
> > 
> > During a connection setup the client confirms that the 
> server key has 
> > been signed by that CA.  This is similar to a trusted 
> anchor, but not 
> > the same.
> > client cert was signed by the "CA on a laptop".  Again, no chain of 
> > trust is permitted.  This policy is incorporating the extra 
> aspect of 
> > "has been inspected by the acceptance team" as part of the 
> > authentication meaning.
> > They decided on a policy-risk basis that there was not a need to 
> > confirm re-inspection, but the "CA on a laptop" did have a 
> revocation 
> > server that was kept available to the servers, so that the 
> acceptance 
> > team could revoke at will.
> > 
> > Policy C:
> > used for external communications by that organization.  All of the 
> > client machines were provided with the certs for the shared servers 
> > (by a method similar to the fingerprint method).  During TLS 
> > connection the clients confirmed that the server cert 
> matched one of 
> > the certs on their list.
> > The
> > responsible for that IP subnet.  The server was configured 
> with a list 
> > of organization CA certs and their corresponding IP subnets.
> > 
> > I do not expect any single policy choice to be appropriate for all 
> > syslog uses.  I think it will be better to encourage a 
> separation of 
> > function in products.  There is more likely to be a commonality of 
> > configuration needs for all users of TLS on a particular 
> system than 
> > to find a commonality of
> > that are likely is more appropriate.  The mandatory 
> verifications can 
> > be separated from the key management system and kept as part of the 
> > protocol definition.  The policy decisions should be left 
> as important
> examples.
> > 
> > Kind Regards,
> > 
> > Research Scientist | HE/Technology Office T  +1 978 897 4860
> > 
> > 07660-2199, United States http://www.agfa.com/healthcare/ Click on 
> > link to read important disclaimer:

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 11 May 2008 20:51:49 -0700

> [mailto:[email-masked]] On Behalf Of Martin Schütte
> Sent: Saturday, May 10, 2008 10:33 AM
> To: [email-masked]
> Subject: [Syslog] why fingerprints? (Re: 
> I-DAction:draft-ietf-syslog-transport-tls-12.txt)
> 
> Am I the only one who finds this whole fingerprint option 
> completely unnecessary?
> Is this practice actually used somewhere? I have not heard 
> about this before and get the impression it is only a bad 
> substitute for copying the peer's certificate.
> 
[Joe] Fingerprints are essentially equivalent to obtaining the peers certificate.  The main advantage a fingerprint has is that it is easier both communicate and perform comparison when a human being is involved.  The main reason for specifying the format is so something that is exported from one implementation can be input into another.  As has been pointed out on the list there can be other ways of obtaining the necessary peer certificate information.  To some user communities fingerprints would be familiar and convenient.  

Certificate fingerprints are used in several places today.  For example, in most web browsers you can view the fingerprint of a server certificate.  In addition SSH uses a similar fingerprint concept for public keys without X.509 certificates.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 11 May 2008 21:10:27 -0700

> Subject: [Syslog] lower requirements? (Re: 
> I do not know if this has been discussed previously, but what 
> is your opinion on lower requirements in order to get 
> transport-tls supported by embedded devices, i.e. switches 
> and printers?
> 
[Joe] TLS is deployed to mitigate certain threats such as those described in the document.  If you fail to mitigate these threats then the value of deploying TLS is diminished.  

> Scenario:
> I could imagine a printer (as the client) having a 
> self-signed certificate and no ability to authenticate the 
> server's certificate.
> As long as the server has a copy of the client's certificate 
> and can verify it, a secure transport is possible. As an 
> admin I would rather configure this one-way authentication 
> and get a TLS-enabled device than having to fall back to UDP.
[Joe] The scenario above does not mitigate server masquerade.  I'm not sure this would be generally acceptable. However, I realize there are systems that work much in this way today.  

> Scenario2:
> Say the same printer with its self-signed cert is 
> configurable with a CA-cert that enables it to authenticate 
> the server (but maybe without checking the certificate's 
> CN/dNSName/IP).
> That would allow a reasonably secure setup. -- Should this be 
> an allowed scenario to be covered by tls-transport?
> In my opinion it should be, thus I would like to keep the 
> requirements on authentication rules as simple as possible.
> 
[Joe] This seems like a workable scenario to me in some environments.   This would require the CA to issue certificates only to authorized parties.  Perhaps the argument can be made to for the configuration of a root as a MUST and the specific types of subject Name checks as RECOMMENDED with the appropriate security considerations discussion.

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 12 May 2008 10:04:50 +0300

Hi Robert,

Section 4.2 includes some requirements for "management interface for
policy decisions" because we need interoperabile security. 

Since TLS doesn't really verify the certificate (except extracting the
public key), in order to get two something-over-TLS implementations to
interoperate, you still need to specify how to configure one end to
accept the certificate of the other end. Traditionally, the answer has
been "just read the PKIX documents", but for small syslog deployments,
we really need something more deployable.

The fingerprint check in draft version -12 attempts to fill this gap.
It's definitely not perfect, or the only possible solution; as you 
note, it's very similar to actually copying the certificate (your 
Policy A below).

The current text requires management interface support for displaying
and configuring fingerprints (instead of displaying and configuring
whole certificates) because it was assumed that for many command line 
and web-based management interfaces, it's much simpler to cut-and-paste 
a short ASCII string instead of a binary file. (And this should make
it more deployable for small syslog environments.)

However, it would be perfectly fine to have a management interface
that also supports exporting/importing whole certificates. Also,
Section 4.2 does not require that a particular deployment actually
uses any of the mandatory-to-implement mechanisms, so all your
policies A/B/C would be OK.

(Also, while Section 4.2 currently has both certification path
validation and fingerprints as mandatory-to-implement, it's
not totally out-of-the-question that only one of them would be
a MUST, and the other one a SHOULD.)

Best regards,
Pasi

> [mailto:[email-masked]] On Behalf Of ext [email-masked]
> Sent: 08 May, 2008 18:53
> Section 4.2 is better, but it still needs work to separate the
> policy decisions from the protocol definition.  Policy decisions are
> driven by risk analysis of the assets, threats, and environment
> (among other things).  These are not uniform over all uses of
> syslog.  That makes it important to separate the policy from the
> protocol, in both the specifications and in the products.
> 
> management and verification will be very similar for a healthcare
> use of syslog. Some healthcare sites would reach the same policy
> decision as is in 4.2, but here are three other policy decisions
> that are also appropriate:
> 
> Policy A:
> certificates for their authorized servers by means of physical
> media, delivered by hand from the security office to the client
> machine support staff.  (The media is often CD-R because it's cheap,
> easy to create, easy to destroy, and easy to use.)  During TLS
> establishment the clients use their assigned private key and the
> server confirms that the connection is from a machine with one of
> the assigned private keys.  The client confirms that the server
> matches one of the provided public certificates by direct matching.
> This is similar to the fingerprint method, but not the same. My most
> recent experience was with an installation using this method.  We
> facilities.  This can only be done by removing as many installation
> schedule dependencies as possible.  The media method removed the
> certificate management dependencies.
> 
> Policy B:
> acceptance team.  The acceptance team has a "CA on a laptop".  After
> accepting safety and function, they establish a direct isolated
> physical connection between the client and the laptop.  Then using
> standard key management tools, the client generates a private key
> and has the corresponding public certificate generated and signed by
> the laptop.  The client is also provided with a public certificate
> for the CA that must sign the certs for all incoming connections.
> 
> During a connection setup the client confirms that the server key
> has been signed by that CA.  This is similar to a trusted anchor,
> but not the same.  There is no chain of trust permitted.  The key
> must have been directly signed by the CA.  During connection setup
> the server confirms that the client cert was signed by the "CA on a
> laptop".  Again, no chain of trust is permitted.  This policy is
> incorporating the extra aspect of "has been inspected by the
> acceptance team" as part of the authentication meaning.  They
> decided on a policy-risk basis that there was not a need to confirm
> re-inspection, but the "CA on a laptop" did have a revocation server
> that was kept available to the servers, so that the acceptance team
> could revoke at will.
> 
> Policy C:
>   This system was for a server that accepted connections from
> several independent organizations.  Each organization managed
> certificates differently, but ensured that the organization-CA had
> signed all certs used for external communications by that
> organization.  All of the client machines were provided with the
> certs for the shared servers (by a method similar to the fingerprint
> method).  During TLS connection the clients confirmed that the
> server cert matched one of the certs on their list. The server
> confirmed that the client cert had been signed by the CA responsible
> for that IP subnet.  The server was configured with a list of
> syslog uses.  I think it will be better to encourage a separation of
> configuration needs for all users of TLS on a particular system than
> to find a commonality of needs for all users of syslog.  The policy
> decisions implicit in section 4.2 make good sense for many uses.
> They are not a complete set.  So a phrasing that explains the kinds
> of maintenance and verification needs that are likely is more
> appropriate.  The mandatory verifications can be separated from the
> key management system and kept as part of the protocol definition.
> The policy decisions should be left as important examples.
> 
> Kind Regards,
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 12 May 2008 22:05:18 +0200

Hi Joe,

Comments inline below....
> From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
> Sent: Monday, May 12, 2008 5:40 AM
> To: Rainer Gerhards; [email-masked]; [email-masked]

I meant

I still think there is a fundamental difference between verifying the
name that is given in the config file and verifying higher level access
control. But, of course, we do not/can not define application design. I
just thought it would be usefule to spell out there is a difference.

> call security "good enough".

I can do this because, from a practical perspective, what most people
are concerned with is confidentiallity. Let me ask a question: how can
we say HTTPS is secure? After all, the HTTPS client is almost never
authenticated against the server. From my practical perspective,
HTTPS-like security, easily enabled by default even for the unskilled
user is much better than "full" security that only exists in theory -
because people turn it off. Security is only as good as the humans using
it...

> the client.  

IMHO the document MUST describe masquerade of both client and server.
Server masquerade is very serious.

>Perhaps access control is not the only way to deal with

See my comment above.

> is pretty much the equivalent of not running security.  

Again, this leads to the conlusion that HTTPS is not running security.

> It might be

As the discusion shows, the threat section seems to be imprecise. It
should discuss the threats in the context of who is protected - client
or server. Obviously, server masquerade is different from server
masquerade. Again, I don't think that server masquerade is less serious.
Just think of hosts/dns spoof attacks fooling the client into sending
data to the wrong server.

Rainer 
> > > decisions from the protocol definition.  Policy decisions 
> are driven
> > by
> > > things).  These are not uniform over all uses of syslog.  
> That makes
> > it
> > > healthcare sites would reach the same policy decision as 
> is in 4.2,
> > but
> > > signed by the CA.  During connection setup the server 
> confirms that
> > the

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 12 May 2008 15:17:44 -0700

Hi Rainer,

Comments below:

<snip>
> > > because it is not possible under the current IESG 
> requirement to be 
> > > safe by default. We cannot be fully safe by default without 
> > > configuration, so whatever we specify will fail for the home user.
> > > 
> I can do this because, from a practical perspective, what 
> most people are concerned with is confidentiallity. Let me 
> ask a question: how can we say HTTPS is secure? After all, 
> the HTTPS client is almost never authenticated against the 
> server. From my practical perspective, HTTPS-like security, 
> easily enabled by default even for the unskilled user is much 
> better than "full" security that only exists in theory - 
> because people turn it off. Security is only as good as the 
> humans using it...
> 
[Joe] We are not talking about HTTPS we are talking about syslog.  What
applies to one may not necessarily apply to the other (HTTP provides
other ways to authenticate the client etc.).  In addition HTTPS
authenticates the server in most cases.  In any case, I don't think you
can claim confidentiality if you do not take care of masquerade or
man-in-the-middle as either will result in a breach of confidentiality,
you are still vulnerable to active attackers.   

I believe that implementations need to support mutual authentication and
authorization with certificates.  The recommended mechanisms for this
probably still need some discussion, however I think it is important to
provide this capability.  I think what is more to the point in the
current discussion is what is required by default.  I would like to
suggest that server authentication, certificate path validation and
authorization be required by default, because I without this I don't
think any security goals are met.  I would also suggest that by default
clients should present and authenticate with a certificate, however a
server does not necessarily need to perform path validation or
authorization, it can just record the certificate (or fingerprint) that
carries the public key used in the authentication so it can be validated
at a later time.  

This requires configuration on the client, but not necessarily on the
server.

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 13 May 2008 07:43:46 +0200

Hi Joe,

[big snip]
> current discussion is what is required by default.  

That is what I was talking about. I do not say that I do not like full
blown security. What I say is that I prefer weaker security even for the
unskilled user in favor of no security. As I wrote, my suggestions were
for the default case.

> I would like to

The server needs to be configured with the client identities.

Anyhow... I think we have exchanged enough arguments for now. We are
right now obviously looking from different angles (skilled users via
home users), which makes it hard to come to a conclusion.

At least I will now continue to implement the current draft. I can
always add different authentication modes later, so it doesn't hurt to
implement a basic set. Plus, the draft allows for anonymous
authentication. I'll make it very easy to turn this on, what probably
solves the home user problem I see.

I'll post notes if I come along anything noteworthy during
implementation.

Rainer

---

From: "tom.petch" <[email-masked]>
Date: Wed, 14 May 2008 09:14:00 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Rainer Gerhards" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, May 13, 2008 12:17 AM
Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt

> carries the public key used in the authentication so it can be validated

Joe

I am concerned, as I think Robert is, about the mixing of protocol and policy;
the former we should define, the latter I am dubious about, seeing it as a
moving target as practices change (one day we may have widespread PKI - or maybe
not:-); at least we should separate it out, section 5 not section 4.

I remain concerned about the number of changes proposed in -12.  Reviewing -11,
last November, we did discuss whether or not the I-D
should give guidance on certificate management and the views I saw then said
not. In fact, dbh asked what IESG-raised issues are we responding to, that is,
given the status of the I-D, the only issues should be IESG ones.  Then, I could
answer that question, now I cannot and so wonder what drives these changes

Historically, the November 2005 IETF meeting led to a proposed charter which was
rejected by the IESG for lacking a mandatory-to-implement security mechanism.
Our AD then guided us through developing a threat model, the rough consensus on
which I believe this I-D accurately records.  This led to a charter which was
acceptable to the IESG.  So that threat model - section 2 - for me is a given.
Change that and you change the charter:-)

During the discussions on threats, rough consensus emerged for TLS.  There was
no discussion about how authentication would be done, no discussion of how
strong the security should be.  The first draft of this I-D took certificates
for granted but did debate the need for client-side authentication. By -11, I
thought that we had a reasonable consensus and should only change what the IESG
wants us to; and that I do not see.

Tom Petch

.