Skip to main content

Signed Syslog Messages
draft-ietf-syslog-sign-29

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    syslog mailing list <syslog@ietf.org>, 
    syslog chair <syslog-chairs@tools.ietf.org>
Subject: Protocol Action: 'Signed syslog Messages' to Proposed Standard

The IESG has approved the following document:

- 'Signed syslog Messages '
   <draft-ietf-syslog-sign-29.txt> as a Proposed Standard


This document is the product of the Security Issues in Network Event Logging Working Group. 

The IESG contact persons are Pasi Eronen and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-29.txt

Ballot Text

Technical Summary

   This document describes a mechanism to add origin authentication,
   message integrity, replay resistance, message sequencing, and
   detection of missing messages to the transmitted syslog messages.
   This specification is intended to be used in conjunction with the
   work defined in RFC 5424, "The Syslog Protocol".

Working Group Summary

   The consensus of the working group was to publish this as a
   standards-track document.

Protocol Quality

   It is possible that there are implementations of this document in
   various stages of completion at this time. Some equipment vendors
   have indicated interest in supporting this document, and some
   non-commercial implementations are also expected.

Personnel

   The document shepherd is David Harrington, and the responsible
   area director is Pasi Eronen.

RFC Editor Note

   In Section 5.2.2, item (b), change both instances of "specifying"
   to "configuring".

   In Sections 9.x, change all occurrences of "IETF Consensus" to
   "IETF Review".

   Insert a new paragraph in Section 1, just before the last paragraph:
	
   "The process of signing works as long as the collector accepts the
   syslog messages, the Certificate Blocks and the Signature Blocks.
   Once that is done, the process is complete.  After that, anyone can
   go back, find the key material, and validate the received messages
   using the information in the Signature Blocks.  Finding the key
   material is very easily done with Key Blob Types C, P, and K (see
   Section 5.2.1) since the public key is in the Payload Block.  If
   Key Blob Types N or U are used, some poking around may be required
   to find the key material. The only way to have a vendor-specific
   implementation is through N or U; however, also in that case the
   key material will have to be available in some form which could be
   used by implementations of other vendors."

RFC Editor Note