Response inline, thanks! > -----Original Message----- > From: Eric Rescorla [mailto:[EMAIL PROTECTED] > Sent: Monday, August 07, 2006 11:38 AM > To: [EMAIL PROTECTED] > 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 [email protected] https://www1.ietf.org/mailman/listinfo/syslog
