Subject: Re: [Syslog] Syslog-sign: Multiple signers on host?

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 1 Aug 2008 19:32:24 -0700

That a valid APP-NAME and PROCID need to be included is a given. Currently, the statement is that originators SHOULD use the same values for those field for every message to be consistent (e.g. section 4.1 and 5.3.1).  Should this "SHOULD" be changed to "MUST" and a statement be added that APP-NAME and PROCID are supposed to uniquely identify a signer on HOSTNAME?  
--- Alex 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Schütte
Sent: Sunday, July 27, 2008 3:51 AM
To: [email-masked]
Subject: Re: [Syslog] Syslog-sign: Multiple signers on host?

[email-masked] schrieb:
> Or maybe something else? Are the APP-NAME/PROCID of any use here?

IMHO the easiest solution would be a requirement for every sender to provide APP-NAME/PROCID information.

Then every originator is determined by the triple (HOSTNAME, APP-NAME,
PROCID) and every signature group by (HOSTNAME, APP-NAME, PROCID, SG, SPRI).

> Section 4.2.2 (about the reboot session ID) also assumes a central 
> syslog process that's tightly coupled with host reboots -- it should 
> be described in terms that make sense in other models, too.

Is it acceptable to use the time(), i.e. seconds since the epoch, as a reboot session ID?

This does "increase whenever an originator reboots" even without the need "to retain the previous Reboot Session ID across reboots" and without any relation to host reboots.

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

---

From: Martin Schütte <[email-masked]>
Date: Mon, 04 Aug 2008 15:49:28 +0200

Alexander Clemm (alex) schrieb:
> That a valid APP-NAME and PROCID need to be included is a given.

Are NILVALUEs valid?

> Currently, the statement is that originators SHOULD use the same
> values for those field for every message to be consistent (e.g.
> section 4.1 and 5.3.1).  Should this "SHOULD" be changed to "MUST"
> and a statement be added that APP-NAME and PROCID are supposed to
> uniquely identify a signer on HOSTNAME?

Yes; if we use these values to distingiush different originators on the 
same host then they MUST be consistent.

I would suggest:
    This specification
    does not mandate particular values for these fields; however, for
    consistency, originators MUST use the same values for APP-NAME,
    PROCID, and MSGID fields for every Certificate Block and Signature
    Block message that is sent for one Signature Group, whichever values
    are chosen. To allow multiple originators per host, these values
    MUST be unique for the duration of the Signature Group.

Intention here:
a) if there is only one originator per hostname possible (use case: on a 
printer) then NILVALUEs are ok, because (together with the HOSTNAME) 
they still identify one originator.
b) I think some time duration is necessary and chosen to impose the 
least restrictions. So the values have to stay the same for one 
Signature Group. That makes sure they can be used as identifiers for 
that Signature Group but leaves enough room for implementations. It is 
then possible to
- restart the daemon, thus changing RSID and PROCID
- use another program, thus changing RSID, APP-NAME, and PROCID
- use different PROCIDs in parallel (use case: one process per Signature 
Group).

One more thing: Except for the APP-NAME alone basically all selections 
from (APP-NAME, PROCID, MSGID) could be used. APP-NAME and PROCID would 
identify one orginator just as well. So if it seems like there could be 
other uses for a MSGID then that does not have to be fixed.

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 4 Aug 2008 16:16:34 -0700

NILVALUEs - as is, they should be valid - actually, this should be stated explicitly in the draft.  The point is that so far they have essentially been "ignored".  

It is possible to differentiate different signers by saying APP-NAME and PROCID are relevant and MUST be used consistently.  It would then also imply that different signers can "reuse" the same SPRI, providing they indicate SG=3 when establishing the signature group.  

Not sure if it was intentional, but you bring up a notion of a duration of a signature group.  This is a different notion than what we have right now.  We only have a notion of a reboot session.  At the beginning of the reboot session, the payload blocks are sent for the various signature groups.  So, the duration is "global" for an originator, not differentiated between signature groups. Now, in principle it is certainly possible to change the semantics of "reboot session" to that of "signature group session".  It does open up a lot of other questions and add complexity, as now a multitude of reboot sessions needs to be kept track of.  Is this really required?  It would seem that we should stick to the simple semantics of reboot session.  Different signers can of course have their own reboot sessions.  So, your text is basically okay, but I would argue that the last sentence must read "To allow multiple originators per host, the values
of APP-NAME and PROCID MUST be unique for the duration of the reboot session."

--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Schütte
Sent: Monday, August 04, 2008 6:49 AM
To: [email-masked]
Subject: Re: [Syslog] Syslog-sign: Multiple signers on host?

Are NILVALUEs valid?

> uniquely identify a signer on HOSTNAME?

Yes; if we use these values to distingiush different originators on the same host then they MUST be consistent.

I would suggest:
    This specification

Intention here:
a) if there is only one originator per hostname possible (use case: on a
printer) then NILVALUEs are ok, because (together with the HOSTNAME) they still identify one originator.
b) I think some time duration is necessary and chosen to impose the least restrictions. So the values have to stay the same for one Signature Group. That makes sure they can be used as identifiers for that Signature Group but leaves enough room for implementations. It is then possible to
- restart the daemon, thus changing RSID and PROCID
- use another program, thus changing RSID, APP-NAME, and PROCID
- use different PROCIDs in parallel (use case: one process per Signature Group).

One more thing: Except for the APP-NAME alone basically all selections from (APP-NAME, PROCID, MSGID) could be used. APP-NAME and PROCID would identify one orginator just as well. So if it seems like there could be other uses for a MSGID then that does not have to be fixed.

---

From: Martin Schütte <[email-masked]>
Date: Tue, 05 Aug 2008 03:59:18 +0200

Alexander Clemm (alex) schrieb:
> It is possible to differentiate different signers by saying APP-NAME
> and PROCID are relevant and MUST be used consistently.  It would then
> also imply that different signers can "reuse" the same SPRI,
> providing they indicate SG=3 when establishing the signature group.

Different signers can also use the same SG. Otherwise it would be 
impossible to have a central log server for many clients (=signers)  ;)

> Not sure if it was intentional, but you bring up a notion of a
> duration of a signature group.  This is a different notion than what
> we have right now.   We only have a notion of a reboot session.  At
> the beginning of the reboot session, the payload blocks are sent for
> the various signature groups.  So, the duration is "global" for an
> originator, not differentiated between signature groups. Now, in
> principle it is certainly possible to change the semantics of "reboot
> session" to that of "signature group session".  It does open up a lot
> of other questions and add complexity, as now a multitude of reboot
> sessions needs to be kept track of.  Is this really required?  It
> would seem that we should stick to the simple semantics of reboot
> session.  Different signers can of course have their own reboot

It was unintentional.
 From the perspective of the originator I implicitly assumed the RSID is 
a global state and a "reboot event" affects all signature groups.
But now that I think of it I do not see that it makes a big difference 
whether "signature group session" were allowed.

The sender can use whatever it wants, so the focus has to be on the 
receiver/verifier and the protocol has to limit its complexity.
Our receiver already has to process different message streams, keep 
track of multiple signature groups from different originators, check 
every signature block's attributes for validity, and recognize new 
reboot sessions from a sender.

Now what constraints do we have when we have when assuming a 
"sender-global" reboot session? And which constraints disappear when we 
allow "signature group sessions"?
I see only the difference between a) finding the signature group and 
comparing the RSID and b) using the RSID as part of the identifier to 
find the signature group. That certainly does not change the overall 
complexity.

---

Just to make my position clear: I think a "sender-global" reboot session 
is just fine; I do not see a serious use case for "signature group 
sessions" and have no intent to 'push' this into the standard.

But on the other hand I do not I do not see a reason to limit the 
possible options without an apparent reason.

---

With regard to the notion of a reboot session I would like to revise my 
previous definition of signature group identifiers to use a more 
hierarchical approach:
ORIGINATOR      := (HOSTNAME, APP-NAME, PROCID)
REBOOT_SESSION  := (ORIGINATOR, VER, RSID)
signature group := (REBOOT_SESSION, SG, SPRI)

Is that closer to your conception?

I am only a bit undecided whether VER identifies a REBOOT_SESSION or a 
signature group inside the REBOOT_SESSION.

> sessions.  So, your text is basically okay, but I would argue that
> the last sentence must read "To allow multiple originators per host,
> the values of APP-NAME and PROCID MUST be unique for the duration of
> the reboot session."

That's fine with me.