Subject: [Syslog] Document shepherd report of AD concerns

From: "David Harrington" <[email-masked]>
Date: Thu, 15 May 2008 14:02:10 -0400

Hi,

Tom asked for a review of the IESG concerns.
As document shepherd, let me address that question.

This email shows the AD comments as the draft progressed since -11-. 
Some WG input was also taken into consideration during the document
revisions.

Following the publication of -11-, Sam Hartman said:
"Dave, the syslog tls document is much clearer and I think it does a
good job of specifying what implementations need to do.
I think  this is a huge improvement.

However  I have two major problems.

1) The default/recommended configuration requires managed trust
   anchors, a working DNS deployment and certificates provisioned to
   syslog servers.  I do not find it plausible that operators will
   actually do this and so I do not find the specification credible.

2) The spec talks about caching of certificates in a manner similar to
    ssh, but does not discuss operational concerns such as key
    rollover.  Jeff, any chance you could help the syslog working
    group understand the tradeoffs around leap of faith?
"

Jeff Hutzelman provided expert advice on behalf of Sam:
"I can try.  It may be worth noting that I don't think ssh talks much
about 
server key rollover, and it certainly isn't done much in practice.
What 
does happen is server keys changing because of a machine being
reinstalled 
or some similar event.  The approaches open to SSH in that case
(prompt the 
user, or just notify them and fail so they can fix it and try again)
don't 
work so well with syslog, where the originator of a message likely
can't 
fix the problem, and the way to notify the person who can is to send a

syslog message!"

Then the AD token passed from Sam to Pasi, who suggested:
"Here's one idea how to handle certificates for TLS in order to make 
it reasonably secure (in most cases), yet also deployable:

- When a tranport sender configures the address of transport receiver,
and enables TLS, allow the following choices:

  1) configure set of trust anchors, and a name to be matched against
     the cert. If the transport receiver address is configured as DNS
     name, this name would usually be the same one. If the transport
     receiver address is configured as IP address, this one could
     be IP address (but could be also a domain name).

     (Note: in no situation, the result of A/AAAA or PTR lookup
     would be used when checking the certificate. This part of the
     current spec isn't correct.)

  2) configure the "certificate fingerprint" of the peer (typically 
     a 40-digit hex string). Cut-and-pasting that from one SSH window 
     to another isn't the world's friendliest UI, but would be doable
     by admins, and is couple of orders of magnitude less work than 
     setting up a real PKI.

  3) configure "anything goes, don't verify the cert" (obviously,  
     not very secure; SHOULD NOT be done)

- A transport receiver would have similar choices:

  1) configure set of trust anchors, and a list of names (or 
     wildcards matching names) to be matched against the
     certificates; everyone listed here would be OK.

  2) configure list of certificate fingerprints that are OK.

  3) configure list of transport (IP) addresses/netmasks that are 
     allowed to send messages regardless of the certificate
     (obviously, not very secure; SHOULD NOT be done)

- I've intentionally omitted "SSH style leap of faith" (called "MAY
  cache the certificate presented by its peer so it can compare the
  certificate with what is presented in subsequent connections" in
  current spec). .

  It could be added (but has some operational issues); or we could
  specify slightly similar (but not quite) functionality where instead
  of typing in the 40-digit fingerprint, the management interface
  would fetch the fingerprint from the peer, show it to the
administrator,
  and the admin would then compare it against something (e.g., what
  he/she sees in some other SSH window), and confirm that they match.
  There are some issues with this, though.... (user studies made with 
  similar approaches show that most users click "yes, they match" even
  when shown two totally different values).

- We probably need to require that everyone must be able to generate a
  keypair and self-signed certificate, and calculate/display the
  fingerprint of the certificate (in some management interface).

Has something like this (in particular, using the fingerprint in 
cases where deploying PKI isn't feasible) suggested before?  Do 
you think it would be operationally workable?

If you think this might make sense, I can post something on the
mailing list, too. But this is just one preliminary idea -- if 
there are other ideas that would solve the issues, I'm in no way
saying it must be done this way."

Joe did a revision which Paso reviewed, and commented:
"Joe: thanks for working on this; I think we're making good
progress, and I'm optimistic that we could get this draft
done soon.

However, some of the TLS/certificate related text in version -11 
was *really*...err... unclear, so I think we need to rewrite
it to some extent before taking it to the WG list (fortunately, 
the whole text is only two pages, so this shouldn't be
too much effort). We also have an option (fingerprints)
that wasn't present before, so we need to recheck the WG 
consensus anyway.

Some proposed text fragments from me (Joe, please feel free 
to edit as you like):

4.2

   TLS typically uses certificates to authenticate
   peers. Authentication and authorization of the TLS server
   (transport receiver) is described in Section 4.2.1; authentication
   and authorization of the TLS client (transport sender) is described
   in Section 4.2.2.

4.2.1 Server authentication/authorization

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

   (Pasi's note: it could be sufficient is one of the following
   two is a MUST, and the other one is a SHOULD.)

   o  Certification path validation and subject name verification: the

      client is configured with one or more trust anchors, and for 
      each transport receiver, the name to be matched against the  
      certificate. This option MUST be supported.

   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.

   o  No server authentication/authorization: The client is configured

      to accept any certificate from the server. This option
      MAY be supported, but MUST NOT be enabled by default.

   For certification path validation, client implementations MUST
   provide a mechanism for configuring one or more trust anchors, and
   MUST perform certification path validation as specified in
   [RFC3280bis].
 
   For subject name verification, client implementations MUST support
   configuring, for each transport receiver, the name to be matched
   against the certificate.  This name may be the host name or IP
   address used when opening the TCP connection, or a distinct host
   name (...details of name matching...MUST support DNS names,
   probably others can be MAY...)

   To support certificate fingerprints, client implementations MUST
   support configuring, for each transport receiver, a fingerprint of
   the server certificate. See Section 4.2.3 for details.

   If server authentication/authorization fails, the client SHOULD log
   the error in some form or another (...more text...)

4.2.2 Client authentication/authorization
  
   The transport receiver (TLS server) has three different options for
   authenticating and authorizing the transport sender (TLS client).

   (Pasi's note: it could be sufficient is one of the following
   two is a MUST, and the other one is a SHOULD.)

   o  Certification path validation and subject name verification:
      the server is configured with one or more trust anchors,
      and a set of names (or wildcard patterns) to be matched 
      against the certificates.  This option MUST be supported.

   o  Certificate fingerprints: The server is configured with the 
      fingerprints of client certificates. This option MUST be
      supported.

   o  No client authentication/authorization (or authorization
      based only on connection source IP address): This option MAY 
      be supported, but MUST NOT be enabled by default.

   Certification path validation and subject name verification work
   as described in Section 4.2.1 above, with following addition: 
   (...locally configured client name can be a wildcard; different 
   from wildcard-in-cert case...)

   To support certificate fingerprints, server implementations MUST
   support configuring with a list of fingerprints of authorized
   certificates. See Section 4.2.3 cor details.

4.2.3 Certificate fingerprints

   Both client and server implementations MUST make the certificate
   fingerprint available through a management interface. If no other
   certificate is configured, both client and server implementations
   MUST support generating a key pair and self-signed certificate.

   <describe details of certificate fingerprint calculation here. 
   this should be compatible with the way e.g. current web browsers
   calculate fingerprints> "

and after Joe did some additioon revising, Pasi said:
"I'd be interested in getting the WG's opinion on this (in
particular, the fingerprint stuff) as soon as possible."

At this point, Joe revised and published the draft and we brought it
to the WG for comment.

Hope this helps

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

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

---

From: <[email-masked]>
Date: Thu, 15 May 2008 22:35:24 +0300

To add to David's email, and Tom's concern that "[we] should only
change what the IESG wants us to to; and that I do not see":

All the changes in version -12 were done in response to my (and
earlier Sam's) AD review comments. However, based on the recent
discussions, it's clear that the text isn't final yet, and needs 
some improvement.

The intent of 4.2.1/4.2.2 was to specify a minimum level needed for
interoperability, not to prevent deployments for making their own
policy decisions. That minimum level can be pretty small -- and
there's some room for discussing what exactly it should be -- but it
must provide reasonable security for many typical syslog uses (and in
this particular case, having a full-fledged PKI as the only approach
isn't really a credible solution).

Perhaps we could rephrase the text to make this more clear, and 
also explain the motivation for these requirements.  Here's a first 
shot at that text -- feedback is welcome.

   To prevent disclosure of syslog message contents, the transport
   sender (TLS client) has to verify that it is sending the messages
   to an authorized transport receiver (TLS server).

   Typically, a client application using TLS achieves this by
   performing certification path validation (using previously
   configured trust anchors), and comparing the certificate subject
   name against the expected server name (or a list of authorized
   server names).
 
   Syslog transport senders MUST support this approach. The minimum
   requirements for certification path validation and subject name
   comparison are specified later in this section.

   However, syslog is frequently used in environments where assuming
   PKI deployment is not realistic. Thus, an alternative that provides
   a reasonable level of security, while being simple to deploy, is
   desired. This document requires that syslog transport senders MUST
   support a mechanism where the authorized transport receivers are
   identified by certificate fingerprints. The minimum requirements
   for this mechanism are specified in Section 4.2.3.

   However, these requirements are intended to specify only a minimum
   level of compliance required for interoperability.  Implementations
   MAY support additional mechanisms for expressing more complex
   policies, validating certificates, and determining whether a
   certificate represents an authorized transport receiver.

   There can be extreme situations where it is not feasible to verify
   that the transport sender is communicating with an authorized
   transport receiver. A syslog implementation MAY provide an option
   to skip this verification (i.e., accept any server certificate).
   This option MUST NOT be enabled by default.

Best regards,
Pasi

> -----Original Message-----
> From: David Harrington
> Sent: 15 May, 2008 21:02
> To: [email-masked]
> Subject: [Syslog] Document shepherd report of AD concerns
> 
> Hi,
>

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 15 May 2008 22:22:09 +0200

Hi Pasi and David,

Thanks for the recent clarifications. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, May 15, 2008 9:35 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Syslog] Document shepherd report of AD concerns
> 
> 

This text is along a fine line of differences: it talks about the sender
checking the server. It is the same model that HTTPS uses (sorry, but
this *is* the analogy). The server is authenticated but the client not.

The text is NOT talking about the server authenticating the client.

Let's look at a syslog.conf line:

*.* @@<server>

Where server is the remote server's name or IP address. This is
(extended) rsyslog syntax, but in essence it is the same for all
implementations. What always must be configured is the name of the
server.

So it is quite easy to check the server identity (again, just like
https) - we can simply compare the name from the cert to what was
configured as <server>. Note that this process is fully automatic if the
sender ships with a set of trusted root certs (like web browsers do) and
the server operator obtained a cert from one of those authorities. As I
said myself, a home user is not likely to pay the associated fee, but a
small biz may do. The advantage is obvious, because we have instant
security without any need to configure anything (that would not be
configured in any case).

A server cert fingerprint requires a bit more of configuration, but can
obviously be a good solution in scenarios where neiterh PKI nor paid
public certs are available.

If we look at the server, there is no such semi-automatic authentication
available. The client can not actually be authenticated. We have a hop
by hop archetecture and we have no required indication of relays inside
the message. So for the server, we can not have a check if client is
authentic (is who it claims it is) but instead we can just have access
control - we can check if the client is permitted to send to us. IMHO
this is different from verifying authenticity. In a relay chain, the
relay may still receive spoofed messages from a relay in front of it. So
we can not autenticate the messages themselfs but only provide access
control for the machine that is connecting to us. Once we are beyond
that stage, we may still receive spoofed, faked, whatever messages. We
can only trust messages if all relays in the chain are configured with
TLS and the same access control. For *nix based syslogds, even that does
not help, because the message on the OS log socket may already be
spoofed.

Thus, I consider authenticating the originator or relay to the receiver
(or relay) quite less important than authenticating the server to the
client. 

This is the reason that I propose to not only split these two modes (as
already happened), but have different minimal requirements for them.

A useful mode to actually authenticate messages is to check the hostname
provided inside the message against the clients certificate. Of course,
this only work on the first hop after the originator, only if we have
syslog-protcol formatted messages and is still somewhat vulnerable to
local log injection in a *nix environment (there is no cure against
that). If one thinks along these lines, it would be quite useful to have
an additional access policy the requires a given server to accept only a
given set of hostnames from a remote client (those that it is permitted
to relay from). This check is probably more useful than the initial
cert-based access control check because it (somewhat) protects against
injecting malicious messages (somewhat, because it still depends on the
full chain being properly protected, it is just easier to detect simpler
attacks, what I find useful).

Just my 2cts... Again, I can live with whatever we specify, because I
can extend it and the current text provides good enough opportunity to
switch back to anonymous authentication by a simple on/off switch (which
defaults to "security on"). But I think it would be useful to get the
best possible defaults. I fear that too-tight requirements are
counter-productive and people will simply turn that switch to "off"
instead of investigating and properly configuring.

Rainer

---

From: "tom.petch" <[email-masked]>
Date: Fri, 16 May 2008 16:37:16 +0200

I think that whatever we say should use consistent terminology.

'Authorization' seems out of place.  I am well familiar with it from SNMP and
isms, as well as from RFC2828, and think that authentication is enough here, as
it is for TLS documents and syslog-protocol.

client and transport sender get used interchangeably, which I think impedes
understanding.  After the initial paranthetic reference to client and server in
this section, I think that we should only use transport sender and transport
receiver.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Fri, 16 May 2008 16:37:24 +0200

Thanks for that, it does allay my concerns (back in November, I got the
impression we were being discouraged from making suggestions and one of my
suggestions, close to the last post on -11, was for self-signed certs with
finger prints:-)

I would go for self-signed cert with finger prints as the minimum acceptable,
with full PKI and leap of faith as the others to mention, essentially as drafted
in -12.

But I do think that -12 gives the wrong impression, that the full
weight of PKI, or self-generating certificates, must be born by whoever is
writing the syslog daemon:-)  That I think is wrong.  Rather, if the box has
PKI, well and good, use it, it will be there for other applications too.  And,
as David has suggested, the box will most likely be initially configured by a
standalone laptop and that will be the one doing the generating, or provision of
the trust anchors, again not just for syslog.

For me, this new material belongs in 5 not 4.  I think 4 as it was in -11 lays
down what an implementor of syslog should do, and that the additional material
belongs in 5, as policy, important to consider but the concern of another (part
of the) organisation.

<rant>
Fundamentally, someone else should be doing this, a policies in security working
group, perhaps a spinoff from pkix or tls (which I know ekr will reject out of
hand:-).  We are the wrong people, IMO, to be proposing resolutions to such
questions; it should be being done for us by those whose primary role is
security, not network management.
</rant>

Finally, Rainer, as ever, is doing a grand job of keeping our feet on the
ground, what is realistic, but, at the time of rchartering, there were three
others who said they would implement this.  I would love to hear their thoughts
on these very implementation-oriented issues.

Tom Petch

---

From: [email-masked]
Date: Fri, 16 May 2008 12:57:31 -0400

>[tom.petch]

I wasn't part of that group, but I am part of the policy world.  It makes 
sense for the syslog group to jointly with some policy people propose that 
"this is a reasonable risk analysis for the use cases that drive our 
protocol".  The purpose of this risk analysis is the derivation of the 
underlying protocol requirements.  But then, it is just the protocol 
requirements that remain normative.  The risk analysis lives on for 
reviewers, so that they have context, and for future users so that they 
can assess whether their real world implementation risks are significantly 
different.  If the real world is different, it just means that you need to 
re-assess whether syslog-tls will meet your needs, will need some extra 
mitigations, or whatever.  This keeps the policy and risk assessment 
portion non-normative.  So when I review something like this for policy I 
want to see the analysis, but not see it become normative.

Real normative policy work does not belong in SDOs at all.  It belongs in 
legislatures, regulatory groups, and business management.  I've seen far 
too many efforts (past and present) where people attempt to use SDOs to 
bypass the public political process.  They think that making it standard 
lets them bypass the ugly and difficult problems of dealing with the 
parliamentary process.  It doesn't work.  It just means that the standards 
become inconsistent with laws and regulations.  That means that 
implementations become inconsistent.  The SDO policy thought needs to 
reflect instead the consideration "what are the range of potential 
policies that will apply" and make sure that the protocol is able to 
support the bulk of those policies.  The extra from the IESG seems to be 
that there be some reasonable baseline policy that is a reasonable subset 
of the bulk of the policies, and mandate that at least that much be 
supported.

That's where I end up with the basic notion of having the various 
certificate stores, some sort of certificate store management, and 
protocol enforcement of certificate verification.  That leaves a baseline 
mandatory policy assumption that there will be bidirectional certificate 
verification within the protocol.  All the rest of policy becomes the 
rules around certificate stores and store management.  Those don't belong 
in syslog standard beyond the requirement that they exist somehow.  Yes, I 
wish there were more agreement on the policies and the resulting needs for 
stores and store management.  I can see syslog contributing it's use cases 
and examples to those needs.  I don't see it incorporating them into the 
standard, or being the right group to define them.

I would not divorce the policy work completely.  Most of the security 
policy work in SDOs has been dealing with human identity management for 
various authentication and authorization purposes.  That is a very 
different application than syslog.  Those use cases do not map well onto 
the automated machine logging application.

R Horn

---

From: "David Harrington" <[email-masked]>
Date: Sun, 18 May 2008 21:00:12 -0400

Hi,

speaking as a contributor ...

I do not believe we should be trying to standardize policy. Policy is
a deployment issue, not an implementation issue.

Our goal should be to provide a mandatory-to-implement mechanism that
operators can enable if desired to protect their messages.

Whether the mechanism is enabled or disabled by default is a decision
that operator/purchasers should discuss with the implemeter/vendors.
It should not be a requirement of the protocol, or the IESG.

There are multiple environments that use syslog. I do not think it is
important to solve the security of syslog messages for environments
where there is no knowledgeable operator. If the operator of a SOHO
device is not clueful enough to cut-and-paste a fingerprint, I doubt
they are clueful enough (or motivated enough) to interpret system
logs. 

I think the OpSec WG is a much better place to discuss policies and
best current practices for logging, including default security
settings. 

This WG should focus only on the mandatory-to-implement security
mechanisms to make it possible for users to address, in a stndardized
manner, security issues in system logging. MUST is for implementers,
not users.

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

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, May 16, 2008 12:58 PM
> To: tom.petch
> Cc: [email-masked]; [email-masked]; syslog; 
> [email-masked]
> > group, perhaps a spinoff from pkix or tls (which I know ekr 
> will reject 
> out of
> > hand:-).  We are the wrong people, IMO, to be proposing 
> resolutions to 
> such

---

From: <[email-masked]>
Date: Mon, 19 May 2008 11:06:24 +0300

Rainer Gerhards wrote:

> This text is along a fine line of differences: it talks about the
> sender checking the server. It is the same model that HTTPS uses
> (sorry, but this *is* the analogy). The server is authenticated but
> the client not.
> 

Yes, the text was intended to clarify Section 4.2.1; Section 4.2.2
also needs similar clarifications (although as you note, the text
isn't necessarily identical, and different requirements for 
minimal compliance could be specified).

> configured as <server>. Note that this process is fully automatic if
> the sender ships with a set of trusted root certs (like web browsers
> do) and the server operator obtained a cert from one of those
> authorities. As I said myself, a home user is not likely to pay the
> associated fee, but a small biz may do. The advantage is obvious,
> because we have instant security without any need to configure
> anything (that would not be configured in any case).
> 
> A server cert fingerprint requires a bit more of configuration, but
> can obviously be a good solution in scenarios where neiterh PKI nor
> paid public certs are available.
> 
> If we look at the server, there is no such semi-automatic
> authentication available. The client can not actually be
> authenticated. We have a hop by hop archetecture and we have no
> required indication of relays inside the message. So for the server,
> we can not have a check if client is authentic (is who it claims it
> is) but instead we can just have access control - we can check if
> the client is permitted to send to us. IMHO this is different from
> verifying authenticity. In a relay chain, the relay may still
> receive spoofed messages from a relay in front of it. So we can not
> autenticate the messages themselfs but only provide access control
> for the machine that is connecting to us. Once we are beyond that
> stage, we may still receive spoofed, faked, whatever messages. We
> can only trust messages if all relays in the chain are configured
> with TLS and the same access control. For *nix based syslogds, even
> that does not help, because the message on the OS log socket may
> already be spoofed.
> 
> Thus, I consider authenticating the originator or relay to the
> receiver (or relay) quite less important than authenticating the
> server to the client.
> 
> This is the reason that I propose to not only split these two modes
> (as already happened), but have different minimal requirements for
> them.
>
> A useful mode to actually authenticate messages is to check the
> hostname provided inside the message against the clients
> certificate.  Of course, this only work on the first hop after the
> originator, only if we have syslog-protcol formatted messages and is
> still somewhat vulnerable to local log injection in a *nix
> environment (there is no cure against that). If one thinks along
> these lines, it would be quite useful to have an additional access
> policy the requires a given server to accept only a given set of
> hostnames from a remote client (those that it is permitted to relay
> from). This check is probably more useful than the initial
> cert-based access control check because it (somewhat) protects
> against injecting malicious messages (somewhat, because it still
> depends on the full chain being properly protected, it is just
> easier to detect simpler attacks, what I find useful).

So far, the security checks in -transport-tls draft have been solely
at the *transport* level, and not concerned with the contents of the
message. (The security considerations text needs to explicitly say 
this, though -- currently, it doesn't.)

Best regards,
Pasi

---

From: <[email-masked]>
Date: Mon, 19 May 2008 11:34:25 +0300

Robert,

We're not attempting to specify policies that deployments are required
to use; we're specifying minimal requirements for management interfaces
to allow interoperability. Such work does belong in the IETF.

Best regards,
Pasi

> From: ext [email-masked] [mailto:[email-masked]] 
> Sent: 16 May, 2008 19:58
> To: tom.petch
> Cc: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki); 
> syslog; [email-masked]
> > Fundamentally, someone else should be doing this, a policies in
> > security working group, perhaps a spinoff from pkix or tls (which
> > I know ekr will reject out of hand:-).  We are the wrong people,
> > IMO, to be proposing resolutions to such questions; it should be
> > being done for us by those whose primary role is security, not
> > network management.
> > </rant>
> >
> 
> I wasn't part of that group, but I am part of the policy world.  It
> makes sense for the syslog group to jointly with some policy people
> propose that "this is a reasonable risk analysis for the use cases
> that drive our protocol".  The purpose of this risk analysis is the
> derivation of the underlying protocol requirements.  But then, it is
> just the protocol requirements that remain normative.  The risk
> analysis lives on for reviewers, so that they have context, and for
> future users so that they can assess whether their real world
> implementation risks are significantly different.  If the real world
> is different, it just means that you need to re-assess whether
> syslog-tls will meet your needs, will need some extra mitigations,
> or whatever.  This keeps the policy and risk assessment portion
> non-normative.  So when I review something like this for policy I
> Real normative policy work does not belong in SDOs at all.  It
> belongs in legislatures, regulatory groups, and business management.
> I've seen far too many efforts (past and present) where people
> attempt to use SDOs to bypass the public political process.  They
> think that making it standard lets them bypass the ugly and
> difficult problems of dealing with the parliamentary process.  It
> doesn't work.  It just means that the standards become inconsistent
> with laws and regulations.  That means that implementations become
> inconsistent.  The SDO policy thought needs to reflect instead the
> consideration "what are the range of potential policies that will
> apply" and make sure that the protocol is able to support the bulk
> of those policies.  The extra from the IESG seems to be that there
> be some reasonable baseline policy that is a reasonable subset of
> the bulk of the policies, and mandate that at least that much be
> supported.
> 
> protocol enforcement of certificate verification.  That leaves a
> baseline mandatory policy assumption that there will be
> bidirectional certificate verification within the protocol.  All the
> rest of policy becomes the rules around certificate stores and store
> management.  Those don't belong in syslog standard beyond the
> requirement that they exist somehow.  Yes, I wish there were more
> agreement on the policies and the resulting needs for stores and
> store management.  I can see syslog contributing it's use cases and
> examples to those needs.  I don't see it incorporating them into the
> I would not divorce the policy work completely.  Most of the
> security policy work in SDOs has been dealing with human identity
> management for various authentication and authorization purposes.
> That is a very different application than syslog.  Those use cases
> do not map well onto the automated machine logging application.
> 
> R Horn