Hi. Here are my AD review comments on version 05 of the syslog udp
transport document. These comments need to be addressed before the
document can be published.
I noticed that you use the term bytes in this document . Please use
octet instead.
Section 4:
bytes in size. This limit ste
A few weeks ago I asked the WG if it believes that the new version of
syslog-protocol represents WG consensus and addresses comments in AD
review.
I have received no response to that question; the document will not
progress until I get a response from the chair on this issue.
--Sam
__
I think these messages may never have made it to the wg.
--- Begin Message ---
Topics:
Re: Prefix - was: RE: [Syslog-sec] AD Review for
Re: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14
Re: [Syslog-sec] AD Review for draft-ietf-syslog-protocol-14
--- End Message ---
--- Begin
> "Anton" == Anton Okmianski (aokmians) <[EMAIL PROTECTED]> writes:
Anton> Section 2 on Terms has this:
Anton> "The words 'byte' and 'octet' are used interchangeably in
Anton> this document.".
I did see that.
Anton> I can change it to:
Anton> "The words 'byte' and 'octe
Hi.
At the meeting yesterday it was fairly obvious that the working group
is interested in considering significant modifications to
draft-ietf-syslog-protocol- . The level of modifications being
seriously discussed make it clear to me that the working group does
not currently have sufficient c
This proposal confuses me greatly. IT seems to be mixing message
formats and over the wire protocol.
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
Hi.
Participants who attend the meetings are expected to also join the
list. It is the consensus on the list that should be driving the
working group, not what decisions are being made in meetings.
--Sam
___
Syslog mailing list
Syslog@lists.ietf.or
Greetings. I'd like to draw yo;ur attention to section 4 of RFC 2418.
This section requires area directors to consult with a working group
prior to concluding that working group. At the meeting in Vancouver I
started such a consultation by noting that once the next set of
milestones is approve
> "Anton" == Anton Okmianski (aokmians) <[EMAIL PROTECTED]> writes:
Anton> Good to have that clear! I also second Rainer that we had
Anton> consensus on the list on everything that is in
Anton> syslog-protocol now. The consensus was built over 2 years,
There are several question
> "Darren" == Darren Reed <[EMAIL PROTECTED]> writes:
>> 2) Is there another charter under which the working group
>> would better be able to make progress?
Darren> I believe the answer to this is yes.
Darren> There is very relevant work this group could do and should
Da
Hi. I did read your message in full and appreciate it greatly.
I'd like to make a few points.
The first is that if meetings aren't working for you and in particular
if they produce different consensus that your list, don't meet. You
don't need to meet. If you decide to ignore the input of the
Hi. Last week had the largest telechat schedule since I've joined the
IESG. I was fairly busy working on document review. Now I'm working
on a long document I need to get done by Wednesday. I hope to finish
early--possibly by lunch today.
Reviewing the syslog charter proposal will be high o
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 Vancouver meeting.
so, you definitely need to have some
> "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
> "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
> "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
> "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> 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
> "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
> "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
Hi.
Can you explain what actions on a part of an attacker are prevented in
terms of attacks on message integrity without authenticating the
source of the message?
In general, the security community is very suspicious of mechanisms
that provide integrity without authentication. If you are going t
I'm concerned that your analysis seems to be based on what is easy to
implement.
We also need to do the analysis of what security is actually required
by syslog deployments.
If the ansers are different, we'll have to deal with that.
But e are in a different situation if we decide to do someth
> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes:
>> I'm concerned that your analysis seems to be based on what is
>> easy to implement.
Rainer> Well, I have to admit that in the world of syslog people
Rainer> vote with their feet. If it is not easy to implement
Ra
> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes:
Rainer> I now understand. But wouldn't it then make sense to
Rainer> create a separate document for it? I have the feeling that
Rainer> would focus us better than when the discussion is split
Rainer> among different plac
> "Balazs" == Balazs Scheidler <[EMAIL PROTECTED]> writes:
Balazs> Although not strictly related to this discussion, but TLS
Balazs> does support kerberos based authentication, see RFC 2712
I just knew someone was going to bring that up.
I really need to right draft-hartmans-tls-271
I agree with your concerns.
I believe the only real issue you need to solve before you are done
with the chartering discussion is whether you are going to have a
transport or whether you are going to use something like syslog-sign.
I *think* that you'll need to know what security threats you cons
> "Tom" == Tom Petch <[EMAIL PROTECTED]> writes:
Tom> More hopefully, I do believe that the threats can be met by
Tom> syslog-sign. Almost every user I talk to about security
Tom> wants encryption. I have to work very hard to do so, but
Tom> mostly succeed, in demonstrating t
May I recommend TLS PSK or TLS in anonymous DH mode in preference to
inventing your own transport that does not use PKI?
Also, before doing something based on shared secrets carefully
consider the requirements of RFC 4107.
___
Syslog mailing list
Sys
> "Tom" == Tom Petch <[EMAIL PROTECTED]> writes:
Tom> The logical conclusion of your approach is that what we need
Tom> is encryption, encryption and encryption, and oh, we could
Tom> throw in a little MAC here and there. I think this makes it
Tom> too complex, too costly with
Tom, I'd like to ask you to give your requirements independent of any
particular implementation biases.
I'm trying to determine if the requirements match what the WG is able
to implement. It doesn't help me do that when people keep mixing the
two issues.
I do completely understand that if we get
Hi. I'm pleased to report that your charter has been approved. It
will take a few days for official word to come out but you can move forward
under this charter.
--Sam
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/list
First, have you looked at the updated IPR disclosure?
You can work on udp and -protocol, and you can even update your
milestones to reflect that. You can get as far as sending me a
publication request for these documents. However I will not take the
documents to the IESG without a security solut
Hi, folks. I had no comments on the UDP draft or the main protocol
draft so I have forwarded them to IETF last call.
I do have some concerns with the TLS draft.
First, I think the idea of generic certificates will not meet with
consensus of the security community. It may be OK to use the same
I'll get back to you on the generic certificates issue. For now, I
recommend you read RFC 4107. Also note that each device needs a
unique MAC address so the manufacturing process tends to have a step
for making a device unique.
So, it sounds like all forms of authentication are optional in th
I failed to write this up yesterday.
Your protocol document uses ISO language identifiers rather than BCP
47. Please either use BCP 47 or explain for all the language sets
that BCP 47 can identify but your choice cannot why syslog
implementations will not care.
___
> "Mark" == Mark Andrews <[EMAIL PROTECTED]> writes:
>> - 'The syslog Protocol ' as
>> a Proposed Standard
Mark> draft-ietf-syslog-protocol-19.txt recommends using a
Mark> reliable protocol. Existing implementations of syslog do
Mark> this and deadlock with nameser
As I said before if you are not going to use BCP 47, you need to
clearly explain for each class of languages BCP 47 supports and your
application does not support why it is OK to be unable to label those
applications.
___
Syslog mailing list
Syslog@lists
> "David" == David Harrington <[EMAIL PROTECTED]> writes:
David> Hi WG, If ISO is a subset of what is covered by BCP047,
David> then would it be acceptable to REQUIRE the ISO subset
David> mandatory-to-implement-for-compliance for interoperability
David> purposes, and implement
> "Mark" == Mark Andrews <[EMAIL PROTECTED]> writes:
>> > "Mark" == Mark Andrews <[EMAIL PROTECTED]> writes:
>>
>> >> - 'The syslog Protocol '
>> as >> a Proposed Standard
>>
Mark> draft-ietf-syslog-protocol-19.txt recommends using a
Mark> reliable protocol.
> "Miao" == Miao Fuyou <[EMAIL PROTECTED]> writes:
Miao> Section 2 identifies masquerade as a major security threat
Miao> for syslog. In the draft, client authentication and server
Miao> authentication are SHOULDs(server authenticaiton may be not
Miao> spelled out explicitly).
> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes:
Rainer> So I would not like to see client and server
Rainer> authentication to be a MUST. Well ... a MUST for an
Rainer> implementation to have that capability would be OK. But an
Rainer> admin must be capable to configu
> "tom" == tom petch <[EMAIL PROTECTED]> writes:
tom> Pity, I had hoped that David's compromise would be
tom> acceptable. RFC4646 (the current BCP0047) is a magnificent
tom> piece of work and does enable the generator of text to
tom> specify quite precisely how it should be in
> "Moehrke," == Moehrke, John (GE Healthcare) <[EMAIL PROTECTED]> writes:
Moehrke,> I would recommend against constraining the key
Moehrke,> management in -tls-. This is a POLICY decision, not a
Moehrke,> protocol decision. (as highlighted by RFC4107)
I'm not sure I disagree with
> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> writes:
>> I wonder why an operator would choose to use a TLS transport
>> without authentication, rather than simply using a non-secure
>> transport.
Rainer> To prevent casual observation. In my experience, this is
Rainer>
What part of 4646 allows non-ASCII characters? How is encoding an
issue?
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
> "Miao" == Miao Fuyou <[EMAIL PROTECTED]> writes:
Miao> Hi, I think there are other things to consider to decide
Miao> SHOULD or MUST an authentication::
Miao> 1, From deployment perspective, it is not very difficult to
Miao> enable server authentication because the populatio
The description of non-ascii characters in the registry refers to
non-ascii characters in the description field, etc. The subtags are
ascii.
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
So, I shouldn't have asked my question and tom shouldn't have replied:
the answer is in the charter.
The threats that this WG will primarily address are modification,
disclosure, and masquerading. A secondary threat is message stream
modification. Threats that will not be addressed by thi
I recommend that you drop message stream modification if my analysis
[At this point, we're still figuring out what we want to say.
I'm speaking as an individual not an AD.]
of the charter is a correct analysis and we meant for that to apply to
syslog-sign.
I recommend you split out peer entity a
> "Miao" == Miao Fuyou <[EMAIL PROTECTED]> writes:
Miao> Yes, peer entity authentication is seperate from integrity,
Miao> this is addressed in section 3 of the current
Miao> document. Client only authenticaiton is not available in
Miao> TLS, so I think it is safe to say "peer
It sounds like trust anchor selection (what security people talk about
when the rest of the world talks about set of root CAs) is actually
very important to you. It's just that you don't actually consider the
traditional root CAs part of your trust anchor set; you have a much
smaller trust anchor
> "Eliot" == Eliot Lear <[EMAIL PROTECTED]> writes:
Eliot> And that leads to my other question. Why are we
Eliot> implementing a separate TLS protocol when 3195 and its
Eliot> successor both exists and has been implemented? That seems
Eliot> to me rather redundant, and violat
> "Eliot" == Eliot Lear <[EMAIL PROTECTED]> writes:
Eliot> Sam, I got involved recently because both chairs asked me
Eliot> to submit a draft to revise 3195 to reflect the work of
Eliot> -protocol-19. I have done so. And so perhaps you can help
Eliot> me.
I'll try!
Elio
Hi. Thanks for the new draft.
There are a lot of changes in this version; it will definitely require
a new ietf last call. I'd recommend that the WG evaluate the changes
and ask whether at this stage in the process they are actually
required. Perhaps they are.
1) You cannot use originator a
I talked to David on the phone and he explained why the WG has chosen
to obselete 3164. His explanation made sense to me so I am no longer
concerned about that.
--Sam
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listin
> "Chris" == Chris Lonvick <[EMAIL PROTECTED]> writes:
Your layer diagram makes sense.
Chris> For discrepancies (if any) between the IP address of the
Chris> "originator" and the "transport sender", the originator can
Chris> use the [origin ip=...] SDE (Section 7.2).
I'd assume
I'd like to draw the attention of the community to section 3 of
draft-ietf-syslog-protocol-21.txt. This text contains text and a
clarified model of the various layers in the syslog architecture and
new terminology for the parties.
I believe this is responsive to the ietf last call comments and
Hi, folks.
I think the WG made a mistake trying to address Chris Newman's comment
about Unicode TR36 and made the situation worse.
My understanding of what the WG was trying to do is to require that if
a BOM is present in a string, then the implementation can enforce
strict checks because it kn
Greetings. Other than the issue I pointed out today, it looks like
we're done with protocol and transport-udp. Once that issue is
resolved I can approve both of these documents and send them to the
rfc-editor.
However, in your discussions with the transport area directors you
made some changes
If the WG is OK with my proposed text, I'll handle it in an rfc editor note
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
60 matches
Mail list logo
