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

[Ballot comment]
My first point was a part of the DISCUSS. I am clearing in anticipation of an RFC Editor note. I've moved it here so that it doesn't disappear from the tracker.

1)
There is one point which is not entirely clear to me. So I would like to discuss it before recommending approval of this document:


5.2.2.  Signer Authentication and Authorization

  b.  X.509 end-entity certificate matching: The collector is
      configured with information necessary to identify the valid end-
      entity certificates of its valid peers, and for each peer, the
      HOSTNAME(s) it is authorized to use.

[...]

      For each peer, the collector MUST support specifying a list of
      HOSTNAME(s) this peer is allowed to use either as FQDNs or IP
      addresses.

How can this MUST be achieved?
Is this again a requirement on management tools? Authors replied that that is the case, but I don't think this is entirely clear from the text.
I think using "collector" to convey this is too subtle.

I would be happy with an extra sentence saying that this is a requirement on management tools, or at least a pointer to the document that defines "collector" as being a management tool.

      Other forms of HOSTNAMEs are beyond the scope of this
      specification.

2)
5.3.2.9.  Example

  <110>1 2009-05-03T14:00:39.519307+02:00 host.example.org syslogd
  2138 - [ssign-cert VER="0111" RSID="1" SG="0" SPRI="0" TPBL="587"
  INDEX="1" FLEN="587" FRAG="2009-05-03T14:00:39.519005+02:00 K BACsLMZ
  NCV2NUAwe4RAeAnSQuvv2KS51SnHFAaWJNU2XVDYvW1LjmJgg4vKvQPo3HEOD+2hEkt1z
  cXADe03u5pmHoWy5FGiyCbglYxJkUJJrQqlTSS6vID9yhsmEnh07w3pOsxmb4qYo0uWQr
  AAenBweVMlBgV3ZA5IMA8xq8l+i8wCgkWJjCjfLar7s+0X3HVrRroyARv8EAIYoxofh9m
  N8n821BTTuQnz5hp40d6Z3UudKePu2di5Mx3GFelwnV0Qh5mSs0YkuHJg0mcXyUAoeYry
  5X6482fUxbm+gOHVmYSDtBmZEB8PTEt8Os8aedWgKEt/E4dT+Hmod4omECLteLXxtScTM
  gDXyC+bSBMjRRCaeWhHrYYdYBACCWMdTc12hRLJTn8LX99kv1I7qwgieyna8GCJv/rEgC
  ssS9E1qARM+h19KovIUOhl4VzBw3rK7v8Dlw/CJyYDd5kwSvCwjhO21LiReeS90VPYuZF
  RC1B82Sub152zOqIcAWsgd4myCCiZbWBsuJ8P0gtarFIpleNacCc6OV3i2Rg=="
  SIGN="AKAQEUiQptgpd0lKcXbuggGXH/dCdQCgdysrTBLUlbeGAQ4vwrnLOqSL7+c="]

It would have been good to see an example of Payload block split into
2 separate Certificate blocks.

3)
9.2.  Version Field

  The third registry that IANA is requested to create is entitled
  "syslog-sign signature scheme values".  It is for the values of the
  Signature Scheme subfield.  The Signature Scheme subfield constitutes
  the fourth octet in the Version field of Signature Blocks and
  Certificate Blocks.  New values shall be assigned by the IANA using
  the "IETF Consensus" policy defined in [RFC5226].  Assigned values
  are to be increased by 1, up to a maximum value of "9".

  This means
  that the same Signature Scheme value can be reserved for different
  Protocol Versions, possibly in each case referring to a different
  Signature Scheme each time.

This doesn't follow from the previous sentence.
I think there is a missing sentence before this one:

"The values are registered relative to the Protocol Version."

  This makes it possible to deal with
  future scenarios in which the single octet representation becomes a
  limitation, as more Signature Schemes can be supported by defining
  additional Protocol Versions that implementations might support
  concurrently.

[Ballot comment]
5.3.2.9.  Example

  <110>1 2009-05-03T14:00:39.519307+02:00 host.example.org syslogd
  2138 - [ssign-cert VER="0111" RSID="1" SG="0" SPRI="0" TPBL="587"
  INDEX="1" FLEN="587" FRAG="2009-05-03T14:00:39.519005+02:00 K BACsLMZ
  NCV2NUAwe4RAeAnSQuvv2KS51SnHFAaWJNU2XVDYvW1LjmJgg4vKvQPo3HEOD+2hEkt1z
  cXADe03u5pmHoWy5FGiyCbglYxJkUJJrQqlTSS6vID9yhsmEnh07w3pOsxmb4qYo0uWQr
  AAenBweVMlBgV3ZA5IMA8xq8l+i8wCgkWJjCjfLar7s+0X3HVrRroyARv8EAIYoxofh9m
  N8n821BTTuQnz5hp40d6Z3UudKePu2di5Mx3GFelwnV0Qh5mSs0YkuHJg0mcXyUAoeYry
  5X6482fUxbm+gOHVmYSDtBmZEB8PTEt8Os8aedWgKEt/E4dT+Hmod4omECLteLXxtScTM
  gDXyC+bSBMjRRCaeWhHrYYdYBACCWMdTc12hRLJTn8LX99kv1I7qwgieyna8GCJv/rEgC
  ssS9E1qARM+h19KovIUOhl4VzBw3rK7v8Dlw/CJyYDd5kwSvCwjhO21LiReeS90VPYuZF
  RC1B82Sub152zOqIcAWsgd4myCCiZbWBsuJ8P0gtarFIpleNacCc6OV3i2Rg=="
  SIGN="AKAQEUiQptgpd0lKcXbuggGXH/dCdQCgdysrTBLUlbeGAQ4vwrnLOqSL7+c="]

It would have been good to see an example of Payload block split into
2 separate Certificate blocks.


9.2.  Version Field

  The third registry that IANA is requested to create is entitled
  "syslog-sign signature scheme values".  It is for the values of the
  Signature Scheme subfield.  The Signature Scheme subfield constitutes
  the fourth octet in the Version field of Signature Blocks and
  Certificate Blocks.  New values shall be assigned by the IANA using
  the "IETF Consensus" policy defined in [RFC5226].  Assigned values
  are to be increased by 1, up to a maximum value of "9".

  This means
  that the same Signature Scheme value can be reserved for different
  Protocol Versions, possibly in each case referring to a different
  Signature Scheme each time.

This doesn't follow from the previous sentence.
I think there is a missing sentence before this one:

"The values are registered relative to the Protocol Version."

  This makes it possible to deal with
  future scenarios in which the single octet representation becomes a
  limitation, as more Signature Schemes can be supported by defining
  additional Protocol Versions that implementations might support
  concurrently.

[Ballot discuss]
Updated as per -29:

There is one point which is not entirely clear to me. So I would like to discuss it before recommending approval of this document:


5.2.2.  Signer Authentication and Authorization

  b.  X.509 end-entity certificate matching: The collector is
      configured with information necessary to identify the valid end-
      entity certificates of its valid peers, and for each peer, the
      HOSTNAME(s) it is authorized to use.

[...]

      For each peer, the collector MUST support specifying a list of
      HOSTNAME(s) this peer is allowed to use either as FQDNs or IP
      addresses.

How can this MUST be achieved?
Is this again a requirement on management tools? Authors replied that that is the case, but I don't think this is entirely clear from the text.
I think using "collector" to convey this is too subtle.

I would be happy with an extra sentence saying that this is a requirement on management tools, or at least a pointer to the document that defines "collector" as being a management tool.

      Other forms of HOSTNAMEs are beyond the scope of this
      specification.

[Ballot comment]
This draft is very hard to understand. I think it needs some high level box and arrows level description of how it works would help implementers get it right.

[Ballot discuss]
I can't find a reference to how one computes the non PGP signatures.

I don't believe that two implementations compliant with this spec would necessarily be able to  interoperable. It has a huge number of options and very weak what must be support by sender and receiver. For example, it not even clear what the mandatory crypto suites are.

I am a bit skeptical that everyone is going to want to implement both the PGP and the X.509 approach. I think it would be better to split to two RFC one for PGP and one for X.509 so vendors could just chose the one they were implementing. Obviously a vendor could implement both but it would help deal with the issue of you when both a sender and receiver implement RFC XXXX, you would know it would work. Did the WG consider this?

On the text requiring a operator acknowledge certain reboots. I can't imagine how to do this on many embedded devices. Is this necessary?

Can you get a Cert with an IP address in it signed by a well know CA? This draft seems to require that.

Reading section 5.2.2, it looks like support for X.509 is SHOULD and support for Open PGP is MAY and X.509 fingerprints is MUST. Is this for both senders and receivers? If so it seems that X.509 in fingerprint mode is only thing that can be counted on. Is that what the WG really wanted?

[Ballot comment]
Section 8.5 states:  "... a reviewer can pinpoint any messages sent by the originator but not
received by reviewing the signature block information."  I don't think this is quite correct.
Since the signature block indicates only the first message number, a reviewer can determine
(a) that one or more messages are missing, and (b) the range in the sequence that particular
message falls in.  The specific missing message can only be determined if it is the first
message in the signature group or the set of messages was sequential (e.g., if the signature
group included messages 3,4,5,6,... and 5 is missing that could be determined).

Anyway, I think the word "pinpoint" is misleading.

[Ballot discuss]
Section 5.2.1 list item b includes the key blob type 'K' -- a bare public key.

Section 5.2.2 specifies two methods for X.509 certificate validation and one method for
validating OpenPGP certificates, but does not specify any method for validating a bare key.
I would assume that a fingerprint mechanism (similar to that specified for OpenPGP) is
the straightforward solution.  I do not see how this mechanism can be interoperable without
specifying a base validation method.

I believe this specification should also clearly state that implementations MUST support
a corresponding validation method for every Key Blob Type it supports.  Other methods can
be supported as well, but for interoperability I think we need a baseline.

[Ballot comment]
I tried to search the document for an explanation of what the
reassembly algorithm is for fragmentation, but found very little material.
On IP we always forgot to specify some safety checks such as prohibiting
overlapping fragments, and had to patch specifications and implementations
later. Perhaps these should be specified here on the first go around?
Or is the situation with syslog different from IP? I admit that there's
probably no firewalls in syslog that were one reason why fragmentation
rules had to be constructed so carefully.

[Ballot discuss]
The document claims to provide a mechanism to allow the detection of missing messages, but doesn't discuss that aspect of the mechanism beyond the short note at the end of the example of one way post-processing could be done. I found it difficult to convince myself that an online-review system could retrain when a message was lost without resorting to behavior like what was described for offline review, and I'm still very unclear on how online-review will retrain after reboot events. Can the document provide clearer guidance to the implementer on how this might be realized?

[Ballot comment]
I agree with Lars on Blind retransmissions. The document seems to be ecouraging this and, while there is a configuration parameter noted, it is unclear whether this is mandatory to implement, and to what value certInitialRepeat should default.

It seems to me that this mechanism is a bit of a hack.

[Ballot comment]
In the text above '... implementes MAY consider ...' the MAY should not be capitalized to be consistent with the other 'may' statements in the same paragraph.

[Ballot discuss]
Section 4.2.2 offers the following option for implementing Reboot Session ID:

> In yet another way, implementers MAY consider
  using the snmpEngineBoots value as a source for this counter as
  defined in [RFC3414].

RFC 3414 defines snmpEngineBoots as 'a count of the number of times the SNMP engine has re-booted/re-initialized since snmpEngineID was last configured'.

It looks like it's necessary to make clear that this manner of implementing Reboot Session ID would work only if there is an SNMP engine at all and if the SNMP engine and the signer always re-boot at the same time.

[Ballot comment]
4.2.8.  Signature

  This is a digital signature, encoded in base 64 per [RFC4648].  The
  signature is calculated over the completely formatted Signature Block
  message (starting from the first octet of PRI and continuing to the
  last octet of MSG, or STRUCTURED-DATA if MSG is not present), before
  the SIGN parameter (SD Parameter Name and the space before it ["
  SIGN"], "=", and the corresponding value) is added.

Did you mean that the digital signature is calculated over the whole
Signature Block message, when ' SIGN="..."' is removed from it?

A clarifying example would be helpful here, or in section 4.2.9.


5.2.1.  Block Format and Fields

  b.  Key Blob Type, a one-octet field containing one of five values:

      1.  'C' -- a PKIX certificate.

A reference is missing here.

5.3.2.9.  Example

  <110>1 2009-05-03T14:00:39.519307+02:00 host.example.org syslogd
  2138 - [ssign-cert VER="0111" RSID="1" SG="0" SPRI="0" TPBL="587"
  INDEX="1" FLEN="587" FRAG="2009-05-03T14:00:39.519005+02:00 K BACsLMZ
  NCV2NUAwe4RAeAnSQuvv2KS51SnHFAaWJNU2XVDYvW1LjmJgg4vKvQPo3HEOD+2hEkt1z
  cXADe03u5pmHoWy5FGiyCbglYxJkUJJrQqlTSS6vID9yhsmEnh07w3pOsxmb4qYo0uWQr
  AAenBweVMlBgV3ZA5IMA8xq8l+i8wCgkWJjCjfLar7s+0X3HVrRroyARv8EAIYoxofh9m
  N8n821BTTuQnz5hp40d6Z3UudKePu2di5Mx3GFelwnV0Qh5mSs0YkuHJg0mcXyUAoeYry
  5X6482fUxbm+gOHVmYSDtBmZEB8PTEt8Os8aedWgKEt/E4dT+Hmod4omECLteLXxtScTM
  gDXyC+bSBMjRRCaeWhHrYYdYBACCWMdTc12hRLJTn8LX99kv1I7qwgieyna8GCJv/rEgC
  ssS9E1qARM+h19KovIUOhl4VzBw3rK7v8Dlw/CJyYDd5kwSvCwjhO21LiReeS90VPYuZF
  RC1B82Sub152zOqIcAWsgd4myCCiZbWBsuJ8P0gtarFIpleNacCc6OV3i2Rg=="
  SIGN="AKAQEUiQptgpd0lKcXbuggGXH/dCdQCgdysrTBLUlbeGAQ4vwrnLOqSL7+c="]

It would have been good to see an example of Payload block split into
2 separate Certificate blocks.


8.2.  Packet Parameters

  Signers need to rigidly enforce the correctness of message bodies.
  Problems may arise if the collector does not fully accept the syslog

What does it mean to "not fully accept"?

  packets sent from an signer, or if it has problems with the format of
  the Certificate Block or Signature Block messages.

9.2.  Version Field

  The third registry that IANA is requested to create is entitled
  "syslog-sign signature scheme values".  It is for the values of the
  Signature Scheme subfield.  The Signature Scheme subfield constitutes
  the fourth octet in the Version field of Signature Blocks and
  Certificate Blocks.  New values shall be assigned by the IANA using
  the "IETF Consensus" policy defined in [RFC5226].  Assigned values
  are to be increased by 1, up to a maximum value of "9".

  This means
  that the same Signature Scheme value can be reserved for different
  Protocol Versions, possibly in each case referring to a different
  Signature Scheme each time.

This doesn't follow from the previous sentence.
I think there is a missing sentence before this one:

"The values are registered relative to the Protocol Version."

  This makes it possible to deal with
  future scenarios in which the single octet representation becomes a
  limitation, as more Signature Schemes can be supported by defining
  additional Protocol Versions that implementations might support
  concurrently.

[Ballot discuss]
There is one point which is not entirely clear to me. So I would like to discuss it before recommending approval of this document:


5.2.2.  Signer Authentication and Authorization

  b.  X.509 end-entity certificate matching: The collector is
      configured with information necessary to identify the valid end-
      entity certificates of its valid peers, and for each peer, the
      HOSTNAME(s) it is authorized to use.

      To ensure interoperability, implementations MUST support
      fingerprints of X.509 certificates as described below.  Other
      methods MAY be supported.

I am confused here. Is this requirement on management tools, or on the protocol itself? I didn't find (or missed) where fingerprints are transferred in the protocol.

      Collectors MUST support key blob type 'C', and specifying the
      list of valid peers using certificate fingerprints.  The
      fingerprint is calculated and formatted as specified in
      [RFC5425], Section 4.2.2.

      For each peer, the collector MUST support specifying a list of
      HOSTNAME(s) this peer is allowed to use either as FQDNs or IP
      addresses.

How can this MUST be achieved? Is this again a requirement on management tools?

      Other forms of HOSTNAMEs are beyond the scope of this
      specification.

[Ballot comment]
4.2.8.  Signature

  This is a digital signature, encoded in base 64 per [RFC4648].  The
  signature is calculated over the completely formatted Signature Block
  message (starting from the first octet of PRI and continuing to the
  last octet of MSG, or STRUCTURED-DATA if MSG is not present), before
  the SIGN parameter (SD Parameter Name and the space before it ["
  SIGN"], "=", and the corresponding value) is added.

Did you mean that the digital signature is calculated over the whole
Signature Block message, when ' SIGN="..."' is removed from it?

A clarifying example would be helpful here, or in section 4.2.9.


5.2.1.  Block Format and Fields

  b.  Key Blob Type, a one-octet field containing one of five values:

      1.  'C' -- a PKIX certificate.

A reference is missing here.

5.3.2.9.  Example

  <110>1 2009-05-03T14:00:39.519307+02:00 host.example.org syslogd
  2138 - [ssign-cert VER="0111" RSID="1" SG="0" SPRI="0" TPBL="587"
  INDEX="1" FLEN="587" FRAG="2009-05-03T14:00:39.519005+02:00 K BACsLMZ
  NCV2NUAwe4RAeAnSQuvv2KS51SnHFAaWJNU2XVDYvW1LjmJgg4vKvQPo3HEOD+2hEkt1z
  cXADe03u5pmHoWy5FGiyCbglYxJkUJJrQqlTSS6vID9yhsmEnh07w3pOsxmb4qYo0uWQr
  AAenBweVMlBgV3ZA5IMA8xq8l+i8wCgkWJjCjfLar7s+0X3HVrRroyARv8EAIYoxofh9m
  N8n821BTTuQnz5hp40d6Z3UudKePu2di5Mx3GFelwnV0Qh5mSs0YkuHJg0mcXyUAoeYry
  5X6482fUxbm+gOHVmYSDtBmZEB8PTEt8Os8aedWgKEt/E4dT+Hmod4omECLteLXxtScTM
  gDXyC+bSBMjRRCaeWhHrYYdYBACCWMdTc12hRLJTn8LX99kv1I7qwgieyna8GCJv/rEgC
  ssS9E1qARM+h19KovIUOhl4VzBw3rK7v8Dlw/CJyYDd5kwSvCwjhO21LiReeS90VPYuZF
  RC1B82Sub152zOqIcAWsgd4myCCiZbWBsuJ8P0gtarFIpleNacCc6OV3i2Rg=="
  SIGN="AKAQEUiQptgpd0lKcXbuggGXH/dCdQCgdysrTBLUlbeGAQ4vwrnLOqSL7+c="]

It would have been good to see an example of Payload block split into
2 separate Certificate blocks.


8.2.  Packet Parameters

  Signers need to rigidly enforce the correctness of message bodies.
  Problems may arise if the collector does not fully accept the syslog

What does it mean to "not fully accept"?

  packets sent from an signer, or if it has problems with the format of
  the Certificate Block or Signature Block messages.

9.2.  Version Field

  The third registry that IANA is requested to create is entitled
  "syslog-sign signature scheme values".  It is for the values of the
  Signature Scheme subfield.  The Signature Scheme subfield constitutes
  the fourth octet in the Version field of Signature Blocks and
  Certificate Blocks.  New values shall be assigned by the IANA using
  the "IETF Consensus" policy defined in [RFC5226].  Assigned values
  are to be increased by 1, up to a maximum value of "9".

  This means
  that the same Signature Scheme value can be reserved for different
  Protocol Versions, possibly in each case referring to a different
  Signature Scheme each time.

This doesn't follow from the previous sentence.
I think there is a missing sentence before this one:

"The values are registered relative to the Protocol Version."

  This makes it possible to deal with
  future scenarios in which the single octet representation becomes a
  limitation, as more Signature Schemes can be supported by defining
  additional Protocol Versions that implementations might support
  concurrently.

[Ballot comment]
Section 1., paragraph 6:
>    The mechanism described in this specification is intended to be used
>    in conjunction with the syslog protocol as defined in [RFC5424] as
>    its message delivery mechanism and uses the concept of STRUCTURED-
>    DATA elements defined in that document.  In fact, this specification
>    mandates implementation of syslog protocol.  Nevertheless, it is
>    conceivable that the concepts underlying this mechanism could also be
>    used in conjunction with other message delivery mechanisms.
>    Designers of other efforts to define event notification mechanisms
>    are therefore encouraged to consider this specification in their
>    designs.

  I don't think it's appropriate for the IETF to make a blanket
  recommendation for this mechanism for other event notifiation systems.
  (I note that the IETF already has other message signing mechanism that
  SYSLOG also did not pick, and probably for good reason.)


Section 3., paragraph 3:
>    While syslog signer and collector implementations MAY support
>    messages with a length larger than 2048 octets, implementers need to
>    be aware that any message truncations that occur render the mechanism
>    useless.

  Wouldn't it make more sense to say that this mechanism MUST NOT be
  applied to messages > 2048 octets, in order to avoid invalid signature
  warnings on the receiver?


Section 5.3.1., paragraph 2:
>    Because certificates can legitimately be much longer than 2048
>    octets, the Payload Block can be split up into several pieces, with
>    each Certificate Block carrying a piece of the Payload Block.  Note
>    that the signer MAY make the Certificate Blocks of any legal length
>    (that is, any length that keeps the entire Certificate Block message
>    within 2048 octets) that holds all the required fields.  Software
>    that processes Certificate Blocks MUST deal correctly with blocks of
>    any legal length.  The length of the fragment of the Payload Block
>    that a Certificate Block carries MUST be at least 1 octet.  The
>    length SHOULD be chosen such that the length of the Certificate Block
>    message does not exceed 2048 octets.

  See above - for reliability reasons, I think 480 octets are a better
  size limit.


Section 5.3.2., paragraph 0:
> 5.3.2.  Certificate Block Format and Fields

  Is there sufficient information in the payload and certificate fields
  to reassemble a fragmented payload block after retransmission under
  loss?


Section 8.2., paragraph 1:
>    As a signer, it is advisable to avoid message lengths exceeding 2048
>    octets.  Various problems might result if a signer were to send
>    messages with a length greater than 2048 octets, because relays MAY
>    truncate messages with lengths greater than 2048 octets which would
>    make it impossible for collectors to validate a hash of the packet.

  See above, this limit should be 480.

[Ballot discuss]
Section 3., paragraph 2:
>    For this
>    reason, syslog signer and collector implementations implementing this
>    specification MUST support messages of up to and including 2048
>    octets in length, in order to minimize the chance of truncation.

  DISCUSS: Relays also need to support 2048-octet messages. But more
  importantly, Section A.2 of RFC5424 has a lot of arguments why for a
  UDP transport, a payload size of 480 octets is really recommended. If
  this mechanism is to be used with SYSLOG over UDP, it would be
  consistent to make the same recommendation here. If the intent is to
  have this be used only with TLS, this needs to be explicitly said
  somewhere.


Section 6.1., paragraph 1:
>    Although the transport sender is not constrained in how it decides to
>    send redundant Signature and Certificate Blocks, or even in whether
>    it decides to send along multiple copies of normal syslog messages,
>    we define some redundancy parameters below which may be useful in
>    controlling redundant transmission from the transport sender to the
>    transport receiver, and which may be useful for administrators to
>    configure.

  DISCUSS: Blind retransmissions will not guarantee reliability but will
  be guaranteed to waste bandwidth. This is a really ugly mechanism.
  Plus, while the section does define "redundancy parameters", it
  doesn't discuss at all what they should be set to under what network
  conditions. It's really easy to misconfigure things such that a
  significant amount of bandwidth is wasted - even when there aren't
  even any actual syslog messages being sent.

IANA questions/comments:

- QUESTION: Can you confirm that all of the assignments in Action
1 should be listed as MANDATORY?

- NOTE: "IETF Consensus" should be replaced by "IETF Review," per
RFC5226.

Upon approval of this document, IANA will create the following:

ACTION 1:

New assignments in the "syslog Structured Data ID Values" registry at
http://www.iana.org/assignments/syslog-parameters

Structured Data ID Structured Data Parameter Required or Optional
Reference
------------------ ------------------------- --------------------
---------
ssign
[RFC-syslog-sign-27]
VER MANDATORY
[RFC-syslog-sign-27]
RSID MANDATORY
[RFC-syslog-sign-27]
SG MANDATORY
[RFC-syslog-sign-27]
SPRI MANDATORY
[RFC-syslog-sign-27]
GBC MANDATORY
[RFC-syslog-sign-27]
FMN MANDATORY
[RFC-syslog-sign-27]
CNT MANDATORY
[RFC-syslog-sign-27]
HB MANDATORY
[RFC-syslog-sign-27]
SIGN MANDATORY
[RFC-syslog-sign-27]

ssign-cert
[RFC-syslog-sign-27]
VER MANDATORY
[RFC-syslog-sign-27]
RSID MANDATORY
[RFC-syslog-sign-27]
SG MANDATORY
[RFC-syslog-sign-27]
SPRI MANDATORY
[RFC-syslog-sign-27]
TPBL MANDATORY
[RFC-syslog-sign-27]
INDEX MANDATORY
[RFC-syslog-sign-27]
FLEN MANDATORY
[RFC-syslog-sign-27]
FRAG MANDATORY
[RFC-syslog-sign-27]
SIGN MANDATORY
[RFC-syslog-sign-27]

QUESTION: From section 4.2 and 5.3.2, we understand that each parameter
is MANDATORY. Please confirm.


ACTION 2:

New sub-registry in the "syslog Parameters" registry located at
http://www.iana.org/assignments/syslog-parameters

Registry Name: syslog-sign protocol version values
Reference: [RFC-syslog-sign-27]
Registration Procedure: IETF Review

value range = unsigned integer 0-99.

Value Description Reference
----- ----------- ---------
00 Reserved [RFC-syslog-sign-27]
01 [RFC-syslog-sign-27]
02-50 Unassigned
51-99 Reserved for Private Use [RFC-syslog-sign-27]


ACTION 3:

New sub-registry in the "syslog Parameters" registry located at
http://www.iana.org/assignments/syslog-parameters

Registry Name: syslog-sign hash algorithm values
Reference: [RFC-syslog-sign-27]
Registration Procedure: IETF Review
Note: new values are assigned incrementally 0->9, then a->z, then A->Z.

Ranges:
value = 0-9,a-z,A-Z. alphanumeric, case sensitive
protocol version = 0-99
hash algorithm = string

Value Protocol Version Hash Algorithm Reference
----- ---------------- -------------- ---------
0 01 Reserved [RFC-syslog-sign-27]
1 01 SHA1 [RFC-syslog-sign-27]
2 01 SHA256 [RFC-syslog-sign-27]


ACTION 4:

New sub-registry in the "syslog Parameters" registry located at
http://www.iana.org/assignments/syslog-parameters

Registry Name: syslog-sign signature scheme values
Reference: [RFC-syslog-sign-27]
Registration Procedure: IETF Review

Ranges:
value = 0-9
protocol version = 0-99
Signature Scheme = string

Value Protocol Version Signature Scheme Reference
----- ---------------- ---------------- ---------
0 01 Reserved [RFC-syslog-sign-27]
1 01 OpenPGP DSA [RFC-syslog-sign-27]
2 01 SHA256 [RFC-syslog-sign-27]


ACTION 5:

New sub-registry in the "syslog Parameters" registry located at
http://www.iana.org/assignments/syslog-parameters

Registry Name: syslog-sign sg field values
Reference: [RFC-syslog-sign-27]
Registration Procedure: IETF Review

Ranges:
value = 0-9
description = string

Value Meaning
----- ----------------
0 per [RFC-syslog-sign-27]
1 per [RFC-syslog-sign-27]
2 per [RFC-syslog-sign-27]
3 per [RFC-syslog-sign-27]
4-7 Unassigned
8-9 Reserved for Private Use [RFC-syslog-sign-27]


ACTION 6:

New sub-registry in the "syslog Parameters" registry located at
http://www.iana.org/assignments/syslog-parameters

Registry Name: syslog-sign key blob type values
Reference: [RFC-syslog-sign-27]
Registration Procedure: IETF Review
Note: Uppercase letters are assigned by IANA. lowercase letters are
vendor specific.

Ranges:
value = A-Z, a-z. ASCII alpha, case sensitive
Key Blob Type = string

Value Key Blob Type Reference
----- ------------------------------------------------- ---------
C a PKIX certificate [RFC-syslog-sign-27]
P an OpenPGP certificate [RFC-syslog-sign-27]
K the public key whose corresponding [RFC-syslog-sign-27]
private key is used to sign the messages
N no key information sent, key is pre-distributed [RFC-syslog-sign-27]
U installation-specific key exchange information [RFC-syslog-sign-27]

PROTO Write-up

1.a) Have the chairs personally reviewed this version of
the Internet Draft (ID), and in particular, do they believe this
ID is ready to forward to the IESG for publication?

Yes.


1.b) Has the document had adequate review from both key WG
members and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

Adequate review has occurred from WG members, and it has been
reviewed by others. I am satisfied about the level of review.


1.c) Do you have concerns that the document needs more
review from a particular (broader) perspective (e.g., security,
operational complexity, someone familiar with AAA, etc.)?

No.


1.d) Do you have any specific concerns/issues with this
document that you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for it.
In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No.


1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong consensus to publish this document.


1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.

No.


1.g) Have the chairs verified that the document adheres
to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.


1.h) Is the document split into normative and informative
references? Are there normative references to IDs, where the IDs are
not also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)

The references are split into normative and informational
references.
The document has normative dependencies on draft-ietf-syslog-protocol-23.txt and draft-ietf-syslog-transport-udp-12.txt, which have been approved, and on draft-ietf-syslog-transport-tls-10.txt which has not yet been approved.



1.ijk) Write-up section:

* 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 xxxx, "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.