Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls
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 authentication as a separate service from integrity. And point out that by integrity, you mean that the sender knows that the data is not modified between the sender and the receiver; by peer entity authentication in this case we want to focus on whether the receiver knows who its peer is. So, perhaps we should cll that sender authentication. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls
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 this WG are DoS and traffic analysis. I knew there was a good reason I asked you guys to come up with that text before we started:-) So, Tom's proposal to focus on data origin authentication as the primary attack is out of charter. Also, the current TLS document seems to have inconsistent terminology with the charter. The charter seems to describe message stream modification as an end-to-end property solved by syslog-sign, while integrity is a hop-by-hop property. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] An early last call comment on protocol-19
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
Re: [Syslog] An early last call comment on protocol-19
- Original Message -
From: "Sam Hartman" <[EMAIL PROTECTED]>
To: "tom.petch" <[EMAIL PROTECTED]>
Cc: "David Harrington" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, February 05, 2007 10:44 PM
Subject: Re: [Syslog] An early last call comment on protocol-19
> What part of 4646 allows non-ASCII characters? How is encoding an
> issue?
Sam
In section 3.1. " Format of the IANA Language Subtag Registry" it says
" Characters from outside the US-ASCII [ISO646] repertoire, as well as
the AMPERSAND character ("&", %x26) when it occurs in a field-body,
are represented by a "Numeric Character Reference" using hexadecimal
notation in the style used by [XML10"
which suggests to me that characters outside the US-ASCII repertoire may occur
in
a language subtag.
.
This section does define the encoding within the IANA Language Subtag Registry
but I do not see that as necessarily defining encodings to be used elsewhere and
I see benefits in using UTF-8 in -protocol should encoding be needed.
I am conscious that section 2.1 of RFC4646 says
"Note that although [RFC4234] refers to octets, the language tags
described in this document are sequences of characters from the
US-ASCII [ISO646] repertoire. Language tags MAY be used in documents
and applications that use other encodings, so long as these encompass
the US-ASCII repertoire."
which supports my view language tags are characters, not an encoding thereof. I
cannot reconcile the reference in 2.1 to US-ASCII repertoire with 3.1 and its
reference to encoding when outside the US-ASCII repertoire.
I note that section 4.4. "Canonicalization of Language Tags" refers to
"Case folding of ASCII letters in certain locales, unless carefully handled,
sometimes produces non-ASCII character values."
with the delightful example of
"the letter 'i' (U+0069) in Turkish and Azerbaijani is uppercased to U+0130"
so on balance, I think that characters outside the US-ASCII repertoire may
occur.
It may be that this is considered too low a probability to consider and that we
limit the language subtags to ASCII, in which case, encoding is not an issue.
I have checked draft-ietf-ltru-4646bis and the wording is unchanged there.
As I said to start with, I do find RFC4646 magnificently powerful, perhaps
too much so, in its entirety, for some use cases.
Tom Petch
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
Re: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls
Tom Petch - Original Message - From: "Sam Hartman" <[EMAIL PROTECTED]> To: "Miao Fuyou" <[EMAIL PROTECTED]> Cc: "'Rainer Gerhards'" <[EMAIL PROTECTED]>; "'David Harrington'" <[EMAIL PROTECTED]>; "'tom.petch'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, February 06, 2007 5:47 AM Subject: Re: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls > > "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 population of > Miao> servers is usually not as many as that of clients, the > Miao> certificates are only required to be created for the server > Miao> rather than plenty of clients: printers, routers and > Miao> hosts. So, I think server authentication is not a major > Miao> reason for the operator to not deploy TLS. > > Keep in mind that if you deploy server authentication you need to > configure all the clients with a trusted set of CAs. > > Miao> However, client > Miao> authentication is highly possible the reason because the > Miao> considerable effort for device certificate deployment. > > Miao> 2, If no authentication exists, it is possible for an > Miao> adversary to launch a MITM attack when TLS connection > Miao> initializes, it talks with server pretending to be client > Miao> and client to server. In this case, no confidentiality and > Miao> integrity is conserved. > > True. > > Miao> So, I would like server authenticaiton to be a MUST rather > Miao> than SHOULD. For client authentication, it may be SHOULD, > Miao> even MAY. > So, you believe that observers seeing messages in transit and > modifying those messages is a more important threat for syslog than > attackers being able to inject fake messages or servers being unable to determine which device a message comes from? > > Also, please remember to structure your thoughts in terms of what > options are mandatory to implement rather than what is mandatory to > deploy. > For me, it is message origin authentication that is the part of security that matters most; confidentiality is less an issue, although I know that there are others on this list for whom the reverse is true. One way I see of achieving this is to make the syslog Device the TLS server and the syslog Collector the TLS client. All syslog devices are given certificates but the role of checking their validity, of identifying trusted CAs, handling certificate chains etc falls on the syslog Collector, which I see as the more powerful engine, with better infrastructure, better able to perform these checks and to reject a TLS server certificate as and when it has doubts. After all, it is the syslog Collector that is misled by faked messages so I see no problem with making it do the work of authentication. Tom Petch ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls
Sam, thanks for the clarification. > What I'm asking for is > > 1) Mandatory behavior such that all implementations can work >together. This includes things like if authentication is going to >be optional to implement, then there must be an option not to >require it. I think it is no problem at all to mandate that implementations implement mutual authentication capabilities. It is a good thing and it is also trivial to do using the current libraries. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls
Sam, The following paragraphs are on how well different authentications address the security threats for syslog. Masquerade, modification and disclosure are identified in the draft as primary threats and message stream modification as secondary threat. Mutual Authentication: Masquerade: fully addressed Modification: fully addressed Disclosure: fully addressed Message Stream Modification: fully addressed Server Authenticaiton Only: Masquerade: partly addressed, the client is left without being authenticated Modification: fully addressed Disclosure: fully addressed Message Stream Modification: fully addressed No Authentication: Masquerade: not addessed Modification: not well addressed because of MITM Disclosure: not well addressed because of MITM Message Stream Modification: not well addressed because of MITM Thanks, Miao > -Original Message- > From: Sam Hartman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 31, 2007 5:37 PM > To: Miao Fuyou > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls > > > 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 this spec. > > You need a clear table describing what attacks are protected > against given each authentication choice. > > > Wording that table so that man-in-the-middle issues are dealt > with correctly and it is still informative will be tricky. > > --Sam > > ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
