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

["Alexander Clemm (alex)" <alex at cisco.com>]

There is one additional aspect, concerning consistency of APP-NAME and PROCID between Signature Block and 
Certificate Block messages. There is currently no statement regarding this, although I believe it makes sense.  


I am putting the following text - please let me know if there are objections:

In section 5.3.1 (on Certification Block messages):
 					Syslog-sign does not mandate particular values for these fields; however, 
					for consistency, implementations MUST use the 
					same value for APP-NAME, PROCID, and MSGID fields for 
					every Certificate Block message, whichever values are chosen.  
					To allow for the possibility of multiple originators per host, 
					the combination of APP-NAME, PROCID, and MSGID MUST be unique for each such originator.  
					If an originator daemon is restarted, it MAY use a new PROCID for what is otherwise the 
					same originator.   The combination of APP-NAME and PROCID MUST 
					be the same that is used for Signature Block messages of the same originator; however, a
					different MSGID MAY be used.  

In section 4.1: (on Signature Block messages): 
				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 Signature Block message that is sent, whichever values are chosen.  
				To allow for the possibility of multiple originators per host, 
				the combination of APP-NAME, PROCID, and MSGID MUST be unique for each such originator.  
				If an originator daemon is restarted, it MAY use a new PROCID for what is otherwise the 
				same originator.    

In section 4.2.2 (on reboot sessions):
					If a reboot of an originator takes place, Signature Block messages MAY use a new PROCID.  
					However, Signature Block messages of the same originator MUST continue to use the 
					same APP-NAME and MSGID, in order 
					to prevent collectors from mistaking the originator.    

--- Alex

-----Original Message-----
From: syslog-bounces at ietf.org [mailto:syslog-bounces at ietf.org] On Behalf Of Martin Schütte
Sent: Monday, August 04, 2008 6:59 PM
To: syslog at ietf.org
Subject: Re: [Syslog] Syslog-sign: Multiple signers on host?

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.

-- 
Martin
_______________________________________________
Syslog mailing list
Syslog at ietf.org
https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog at ietf.org
https://www.ietf.org/mailman/listinfo/syslog