Hi,
On Tue, 10 Jan 2006, Balazs Scheidler wrote:
On Tue, 2006-01-10 at 22:02 +1100, Darren Reed wrote:
On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote:
I would say that addressing the security concerns at the transport level
is way easier management and implementation wise than imple
On Tue, 2006-01-10 at 22:02 +1100, Darren Reed wrote:
> > On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote:
> >
> > I would say that addressing the security concerns at the transport level
> > is way easier management and implementation wise than implementing
> > syslog-sign.
>
> I disagr
> > 1) transport level implements security mechanisms on a per
> hop-by-hop
> > basis, the message itself is not authenticated, each of the relay
> > stations can modify the message
> >
> > 2) syslog-sign implements per-message, end-to-end
> authenticity where the
> > relay hosts cannot modify m
> On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote:
>
> I would say that addressing the security concerns at the transport level
> is way easier management and implementation wise than implementing
> syslog-sign.
I disagree with the statement about management as the problem is the
same fo
I agree with Balazs suggestion and his reasoning.
Rainer
> -Original Message-
> From: Balazs Scheidler [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 10, 2006 10:52 AM
> To: Rainer Gerhards
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Syslog] Charter comments from I
On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote:
> Of course, a threat model should also be developed, but please keep in
> mind that anything other than signatures breaks what this WG has fought
> for since Vancouver.
>
> syslog-protocol should be finished (I hope we are there soon) as
> "Tom" == Tom Petch <[EMAIL PROTECTED]> writes:
Tom> without committing us to either a -sign or a secure transport
Tom> approach (and yes, we did start the transport wars, some time
Tom> ago, with SSH v TLS:-(
I really think that you need to identify your deliverables in the
cha
Petch
- Original Message -
From: "Sam Hartman" <[EMAIL PROTECTED]>
To: "Rainer Gerhards" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, January 09, 2006 2:35 PM
Subject: Re: [Syslog] Charter comments from IESG Review
> >>>>>
> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes:
Rainer> This looks like I misunderstood your intension. I thought
Rainer> that unsecured UDP should no longer be supported.
That was not my intent.
Rainer> So what
Rainer> you actually said is that we can go ahead wit
Sam,
> Rainer> Why? Simply
> Rainer> because any transport-layer requirement (DTSL, SSL, SSH,
> Rainer> whatever) would NOT be compatible with currently existing
> Rainer> syslog implementations. So due to this requirement, we can
> Rainer> not create a backwards-compatible sp
> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes:
Rainer> Sorry, yes, I was totally wrong in my wording. What I
Rainer> intended to say was that the keys are exchanged on a
Rainer> medium different then the current session (e.g. key
Rainer> servers).
This is not typic
> -Original Message-
> From: Sam Hartman [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 09, 2006 1:08 PM
> To: Rainer Gerhards
> Cc: Tom Petch; [EMAIL PROTECTED]
> Subject: Re: [Syslog] Charter comments from IESG Review
>
> >>>>> "Rainer&qu
> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes:
Rainer> Tom,
>> > If so, yes, both S/MIME and OpenPGP support this model.
>> However I'll > point oun that it is not a requirement that
>> syslog work that way; for > example RFC 3195 certainly has
>> connections.
> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes:
Rainer> Hi Sam & WG, I understand the reasoning behind requiring a
Rainer> security mechanism. I just want to remind everyone that a
Rainer> major drawback in Vancouver was that we had lost some
Rainer> backwards-compati
Tom,
> > If so, yes, both S/MIME and OpenPGP support this model.
> However I'll
> > point oun that it is not a requirement that syslog work
> that way; for
> > example RFC 3195 certainly has connections.
> >
> I'll look at those, thanks. I agree syslog could be, perhaps
> should be for
> mean
Chris,
> > 1) Require some transport like syslog over TLS|DTLS be implemented.
>
> RFC 3195 requires the use of RFC 3080 which requires TLS.
small glitch: RFC 3080 provides support for a TLS profile, but it does
not mandate it. Most existing RFC 3195 implementations do NOT support
the TLS tunin
Hi Sam & WG,
I understand the reasoning behind requiring a security mechanism. I just
want to remind everyone that a major drawback in Vancouver was that we
had lost some backwards-compatibility to existing syslog
implementations.
The weeks after Vancouver we worked hard to find a minimum consens
- Original Message -
From: "Sam Hartman" <[EMAIL PROTECTED]>
To: "Tom Petch" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, January 06, 2006 10:27 PM
Subject: Re: [Syslog] Charter comments from IESG Review
> >>>>> "T
> "Tom" == Tom Petch <[EMAIL PROTECTED]> writes:
Tom> Sam I struggle to think what a security system would look
Tom> like when the protocol is purely simplex, apart from a MAC to
Tom> give integrity with some shared secret transmitted totally
Tom> out of band.
By this do you m
Sam
I struggle to think what a security system would look like when the protocol is
purely simplex, apart from a MAC to give integrity with some shared secret
transmitted totally out of band.
Are there any examples of simplex security elsewhere in the IETF?
Tom Petch
- Original Message
> "Chris" == Chris Lonvick <[EMAIL PROTECTED]> writes:
Chris> Is Section 8 in draft-ietf-syslog-protocol-16.txt
Chris> sufficient? Alternatively, Section 6 in RFC 3164 is fairly
Chris> comprehensive.
Both of these look good. My main question with them is whether you
believe it i
Hi Sam,
On Thu, 5 Jan 2006, Sam Hartman wrote:
Hi. The IESg reviewed the proposed syslog charter at today's telechat
and decided that it requires revision. The main concern seems to be
the lack of a mandatory to implement security mechanism. I indicated
this might be the case in the Vancou
22 matches
Mail list logo
