RE: [Syslog] Notes on TLS transport

Miao Fuyou <miaofy@huawei.com> Mon, 07 August 2006 12:45 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA4Tz-0003iO-Me; Mon, 07 Aug 2006 08:45:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GA4Ty-0003h3-32 for syslog@ietf.org; Mon, 07 Aug 2006 08:45:22 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA1j7-0003Nn-Nn for syslog@ietf.org; Mon, 07 Aug 2006 05:48:49 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GA1fR-0005n5-A2 for syslog@ietf.org; Mon, 07 Aug 2006 05:45:02 -0400
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3M00JDUGIMXD@szxga03-in.huawei.com> for syslog@ietf.org; Mon, 07 Aug 2006 17:47:11 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3M00AR8GIMIB@szxga03-in.huawei.com> for syslog@ietf.org; Mon, 07 Aug 2006 17:47:10 +0800 (CST)
Received: from m19684 ([10.111.12.140]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3M00K23GLA2W@szxml04-in.huawei.com> for syslog@ietf.org; Mon, 07 Aug 2006 17:48:50 +0800 (CST)
Date: Mon, 07 Aug 2006 17:36:56 +0800
From: Miao Fuyou <miaofy@huawei.com>
Subject: RE: [Syslog] Notes on TLS transport
In-reply-to: <20060807034541.13121222425@laser.networkresonance.com>
To: 'Eric Rescorla' <ekr@networkresonance.com>, syslog@ietf.org
Message-id: <008c01c6ba05$069ea1a0$8c0c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: Aca50utioaRZSX13SC6e3n4933UtuwAKqUuA
X-Spam-Score: -2.3 (--)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc:
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

Response inline, thanks! 

> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@networkresonance.com] 
> Sent: Monday, August 07, 2006 11:38 AM
> To: syslog@ietf.org
> Subject: [Syslog] Notes on TLS transport
> 
> S 5.2:
>    TLS uses certificate [5] to authenticate the peers.  When a sender
>    authenticates a receiver it MUST validate the certificate. 
>  It SHOULD
>    check the common name(CN) of the certificate against the 
> host name of
>    the receiver if it has knowledge of a common name/host 
> name mapping.
>    If the common name does not match the host name, the sender SHOULD
>    send an "access_denied" error alert using the TLS alert protocol to
>    terminate the handshake, and then it SHOULD close the connection.
> 
> Do you want to cite RFC 2818 here?
> 
> Also, some clarity about whether the sender is expected to validate
> the receiver's cert would be helpful. Similarly, is sender auth
> required?

A very brief clarification about server authentication is in section 6.1
(last sentence). Sender authentication is preferrable when DoS is a concern,
an unauthenticated sender may send spurios spurios Syslog messages to
receiver. But, the threat model in this document explicitly excludes denial
of service. 

> 
> S 6.2:
> 
>    When a certificate is issued to a class of device or 
> application, the
>    certificate may be shared by multiple hosts.  Multiple 
> hosts know the
>    private key of the certificate. When the certificate in one host is
>    compromised, then the certificate for all hosts that share the
>    certificate is compromised. Any communication that is bound to the
>    certificate is at risk.
> 
> It depends what you mean "at risk". Say you have two clients who
> share the same cert. If client A is compromised, then the attacker
> can impersonate client B, but it can't view data on or tamper
> with a channel that client B actually established. The situation
> is a bit more complicated for servers and depends on which cipher
> suite you're using (PFS of not).
> 

Thanks, very good clarification. I will update the text. BTW, generic
certificate are only issued to senders, server would not be issued a generic
certificate.

> 
> S 6.3:
>    Different applications in the same host may have different security
>    levels (e.g., the kernel may have higher a security level than a
>    document editor application). If a requested session resumes an
>    existing session, then the requesting application can decrypt the
>    Syslog messages of the resumed session using same cipher parameters
>    as defined for the resumed session. When a session is being resumed
>    from an application with a different security level, care must be
>    taken to avoid disclosing sensitive data to an unauthorized
>    application.  A sensitive session must not be resumable.
> 
> This isn't clear to me. It depends a lot on how the keying material
> is handled. You need to explain the threat model a lot more 
> clearly here..
> 

Yes. there is problem for this text.  I checked 4346bits, ClientHello.Random
and ServerHello.Random is used in 4346bis to make encryption key and MAC
secrets different for resumed sessions. So, I may drop this paragraphy from
this document.




_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog