Subject: RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls

From: Miao Fuyou <[email-masked]>
Date: Fri, 02 Feb 2007 11:28:21 +0800

Section 2 identifies masquerade as a major security threat for syslog. In
the draft, client authentication and server authentication are
SHOULDs(server authenticaiton may be not spelled out explicitly). After
reading RFC2818 once again, I think the server authentication may have to be
a MUST for the specification to mitigate the MITM, while client
authentication (mutual authentication actually) may still be kept SHOULD. 

If generic certificate is not right to be reccomended in an IETF
specification, probably we have to remove it from the draft.

Thanks!
Miao

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Wednesday, January 31, 2007 5:37 PM
> To: Miao Fuyou
> Cc: [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Sam Hartman <[email-masked]>
Date: Thu, 01 Feb 2007 23:30:11 -0500

>>>>> "Miao" == Miao Fuyou <[email-masked]> 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). After reading RFC2818 once again, I
    Miao> think the server authentication may have to be a MUST for
    Miao> the specification to mitigate the MITM, while client
    Miao> authentication (mutual authentication actually) may still be
    Miao> kept SHOULD.

You can also decide to document that if you care about MITM you need
authentication.  My point was not to change your decisions, simply to
require that you provide an easy way for people to know what security
they are getting based on what they are doing.

I've talked to Russ Housley and we will not take a document to the
IESG that recommends the reuse of private keys, so the generic
certificates section needs to go.

You could talk about how devices could be identified by some component
of a subject name or subject alternative name and such mechanisms can
be used to identify all the devices from a manufacturer; that's true
regardless of whether generic certificates are used or one certificate
per device.

---

From: Miao Fuyou <[email-masked]>
Date: Tue, 06 Feb 2007 16:38:37 +0800

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Feb 2007 10:55:34 -0500

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.

---

From: Miao Fuyou <[email-masked]>
Date: Wed, 07 Feb 2007 17:13:33 +0800

Yes, peer entity authentication is seperate from integrity, this is
addressed in section 3 of the current document. Client only authenticaiton
is not available in TLS, so I think it is safe to say "peer entity
authention" instead of sender authenticaiton. 

Probably it is appropriate to say something in section 3 of the document
like "Secure transport only secures syslog in a hop by hop manner, end to
end message stream modificationis threat is not addressed in this document".

Thanks,
Miao

> Sent: Tuesday, February 06, 2007 11:56 PM
> To: Miao Fuyou
> Cc: [email-masked]
> 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.
> 
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Feb 2007 07:13:01 -0500

>>>>> "Miao" == Miao Fuyou <[email-masked]> 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 entity authention"
    Miao> instead of sender authenticaiton.

No, because peer entity authentication confuses server auth and
client+server auth.

Also, TLS does have client only auth: any case where the server cert
is not actually verified but the client certificate is.

It's important for the TLS document to point out that authentication
is as much about whether you actually check the certificates as
whether you exchange them at a protocol level.