< draft-ietf-syslog-transport-tls-13.txt   draft-ietf-syslog-transport-tls-14.txt >
Syslog Working Group F. Miao, Ed. Syslog Working Group F. Miao, Ed.
Internet-Draft Y. Ma, Ed. Internet-Draft Y. Ma, Ed.
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: December 20, 2008 J. Salowey, Ed. Expires: April 3, 2009 J. Salowey, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
June 18, 2008 September 30, 2008
TLS Transport Mapping for Syslog TLS Transport Mapping for Syslog
draft-ietf-syslog-transport-tls-13.txt draft-ietf-syslog-transport-tls-14.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 20, 2008. This Internet-Draft will expire on April 3, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes the use of Transport Layer Security (TLS) to This document describes the use of Transport Layer Security (TLS) to
provide a secure connection for the transport of syslog messages. provide a secure connection for the transport of syslog messages.
This document describes the security threats to syslog and how TLS This document describes the security threats to syslog and how TLS
skipping to change at page 2, line 24 skipping to change at page 2, line 24
4.2.1. Certificate-Based Authentication . . . . . . . . . . . 5 4.2.1. Certificate-Based Authentication . . . . . . . . . . . 5
4.2.2. Certificate Fingerprints . . . . . . . . . . . . . . . 6 4.2.2. Certificate Fingerprints . . . . . . . . . . . . . . . 6
4.2.3. Cryptographic Level . . . . . . . . . . . . . . . . . 7 4.2.3. Cryptographic Level . . . . . . . . . . . . . . . . . 7
4.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. Message Length . . . . . . . . . . . . . . . . . . . . 7 4.3.1. Message Length . . . . . . . . . . . . . . . . . . . . 7
4.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Policies . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Policies . . . . . . . . . . . . . . . . . . . . . . 8
5.1. End-Entity Certificate Based Authorization . . . . . . . . 8 5.1. End-Entity Certificate Based Authorization . . . . . . . . 8
5.2. Subject Name Authorization . . . . . . . . . . . . . . . . 9 5.2. Subject Name Authorization . . . . . . . . . . . . . . . . 9
5.3. Unauthenticated Transport Sender . . . . . . . . . . . . . 9 5.3. Unauthenticated Transport Sender . . . . . . . . . . . . . 9
5.4. Unauthenticated Transport Receiver . . . . . . . . . . . . 9 5.4. Unauthenticated Transport Receiver . . . . . . . . . . . . 10
5.5. Unauthenticated Transport Receiver and Sender . . . . . . 10 5.5. Unauthenticated Transport Receiver and Sender . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1. Authentication and Authorization Policies . . . . . . . . 10 6.1. Authentication and Authorization Policies . . . . . . . . 10
6.2. Name Validation . . . . . . . . . . . . . . . . . . . . . 11 6.2. Name Validation . . . . . . . . . . . . . . . . . . . . . 11
6.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from -12 . . . . . . . . . . . . . . . . . . 12 Appendix A. Changes from -12 . . . . . . . . . . . . . . . . . . 12
Appendix B. Changes from -13 . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
This document describes the use of Transport Layer Security (TLS This document describes the use of Transport Layer Security (TLS
[I-D.ietf-tls-rfc4346-bis]) to provide a secure connection for the [RFC5246]) to provide a secure connection for the transport of syslog
transport of syslog [I-D.ietf-syslog-protocol] messages. This [I-D.ietf-syslog-protocol] messages. This document describes the
document describes the security threats to syslog and how TLS can be security threats to syslog and how TLS can be used to counter such
used to counter such threats. threats.
1.1. Terminology 1.1. Terminology
The following definitions are used in this document: The following definitions are used in this document:
o An "originator" generates syslog content to be carried in a o An "originator" generates syslog content to be carried in a
message. message.
o A "collector" gathers syslog content for further analysis. o A "collector" gathers syslog content for further analysis.
o A "relay" forwards messages, accepting messages from originators o A "relay" forwards messages, accepting messages from originators
or other relays, and sending them to collectors or other relays. or other relays, and sending them to collectors or other relays.
o A "transport sender" passes syslog messages to a specific o A "transport sender" passes syslog messages to a specific
transport protocol. transport protocol.
o A "transport receiver" takes syslog messages from a specific o A "transport receiver" takes syslog messages from a specific
transport protocol. transport protocol.
o A "TLS client" is an application that can initiate a TLS o A "TLS client" is an application that can initiate a TLS
connection by sending a Client Hello to a peer. connection by sending a Client Hello to a server.
o A "TLS server" is an application that can receive a Client Hello o A "TLS server" is an application that can receive a Client Hello
from a peer and reply with a Server Hello. from a client and reply with a Server Hello.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Security Requirements for Syslog 2. Security Requirements for Syslog
Syslog messages may transit several hops to arrive at the intended Syslog messages may transit several hops to arrive at the intended
collector. Some intermediary networks may not be trusted by the collector. Some intermediary networks may not be trusted by the
originator, relay, or receiver because the network is in a different originator, relay, or receiver because the network is in a different
skipping to change at page 5, line 31 skipping to change at page 5, line 31
and remove this note. and remove this note.
4.2. Initiation 4.2. Initiation
The transport sender should initiate a connection to the transport The transport sender should initiate a connection to the transport
receiver and then send the TLS Client Hello to begin the TLS receiver and then send the TLS Client Hello to begin the TLS
handshake. When the TLS handshake has finished the transport sender handshake. When the TLS handshake has finished the transport sender
MAY then send the first syslog message. MAY then send the first syslog message.
TLS typically uses certificates [RFC5280] to authenticate peers. TLS typically uses certificates [RFC5280] to authenticate peers.
Implementations MUST support TLS 1.2 [I-D.ietf-tls-rfc4346-bis] and Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to
are REQUIRED to support the mandatory to implement cipher suite, support the mandatory to implement cipher suite, which is
which is TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to
apply to future versions of TLS, in which case the mandatory to future versions of TLS, in which case the mandatory to implement
implement cipher suite for the implemented version MUST be supported. cipher suite for the implemented version MUST be supported.
4.2.1. Certificate-Based Authentication 4.2.1. Certificate-Based Authentication
Both syslog transport sender (TLS Client) and syslog transport Both syslog transport sender (TLS Client) and syslog transport
receiver (TLS server) MUST implement certificate-based receiver (TLS server) MUST implement certificate-based
authentication. This consists of validating the certificate and authentication. This consists of validating the certificate and
verifying that the peer has the corresponding private key. The verifying that the peer has the corresponding private key. The
latter part is performed by TLS. To ensure interoperability between latter part is performed by TLS. To ensure interoperability between
clients and servers, the following methods for certificate validation clients and servers, the following methods for certificate validation
SHALL be implemented: SHALL be implemented:
skipping to change at page 6, line 32 skipping to change at page 6, line 32
another mechanism. another mechanism.
The transport receiver and transport sender SHOULD provide mechanisms The transport receiver and transport sender SHOULD provide mechanisms
to record the end-entity certificate for the purpose of correlating to record the end-entity certificate for the purpose of correlating
it with the sent or received data. it with the sent or received data.
4.2.2. Certificate Fingerprints 4.2.2. Certificate Fingerprints
Both client and server implementations MUST make the certificate Both client and server implementations MUST make the certificate
fingerprints for their certificate available through a management fingerprints for their certificate available through a management
interface. interface. The labels for the algorithms are taken from the textual
names of the hash functions as defined in the IANA registry "Hash
Function Textual Names" allocated in [RFC4572].
The mechanism to generate a fingerprint is to take the hash of the The mechanism to generate a fingerprint is to take the hash of the
DER-encoded certificate using a cryptographically strong algorithm DER-encoded certificate using a cryptographically strong algorithm
and convert the result into colon separated, hexadecimal bytes, each and convert the result into colon separated, hexadecimal bytes, each
represented by 2 uppercase ASCII characters. When a fingerprint represented by 2 uppercase ASCII characters. When a fingerprint
value is displayed or configured the fingerprint is prepended with an value is displayed or configured the fingerprint is prepended with an
ASCII label identifying the hash function followed by a colon. ASCII label identifying the hash function followed by a colon.
Implementations MUST support SHA-1 as the hash algorithm and use the Implementations MUST support SHA-1 as the hash algorithm and use the
ASCII label "SHA1" to identify the SHA-1 algorithm. The length of a ASCII label "sha-1" to identify the SHA-1 algorithm. The length of a
SHA-1 hash is 20 bytes and the length of the corresponding SHA-1 hash is 20 bytes and the length of the corresponding
fingerprint string is 64 characters. An example certificate fingerprint string is 65 characters. An example certificate
fingerprint is: fingerprint is:
SHA1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
During validation the hash is extracted from the fingerprint and During validation the hash is extracted from the fingerprint and
compared against the hash calculated over the received certificate. compared against the hash calculated over the received certificate.
4.2.3. Cryptographic Level 4.2.3. Cryptographic Level
Syslog applications SHOULD be implemented in a manner that permits Syslog applications SHOULD be implemented in a manner that permits
administrators, as a matter of local policy, to select the administrators, as a matter of local policy, to select the
cryptographic level and authentication options they desire. cryptographic level and authentication options they desire.
skipping to change at page 8, line 7 skipping to change at page 8, line 7
SYSLOG-FRAME. A transport receiver MUST use the message length to SYSLOG-FRAME. A transport receiver MUST use the message length to
delimit a syslog message. There is no upper limit for a message delimit a syslog message. There is no upper limit for a message
length per se. However, in order to establish a baseline for length per se. However, in order to establish a baseline for
interoperability, this specification requires that a transport interoperability, this specification requires that a transport
receiver MUST be able to process messages with a length up to and receiver MUST be able to process messages with a length up to and
including 2048 octets. Transport receiver SHOULD be able to process including 2048 octets. Transport receiver SHOULD be able to process
messages with lengths up to and including 8192 octets. messages with lengths up to and including 8192 octets.
4.4. Closure 4.4. Closure
A TLS client MUST close the associated TLS connection if the A transport sender MUST close the associated TLS connection if the
connection is not expected to deliver any syslog messages later. It connection is not expected to deliver any syslog messages later. It
MUST send a TLS close_notify alert before closing the connection. A MUST send a TLS close_notify alert before closing the connection. A
client MAY choose to not wait for the server's close_notify alert and transport sender (TLS client) MAY choose to not wait for the
simply close the connection, thus generating an incomplete close on transport receiver's close_notify alert and simply close the
the server side. Once the server gets a close_notify from the connection, thus generating an incomplete close on the transport
client, it MUST reply with a close_notify unless it becomes aware receiver (TLS server) side. Once the transport receiver gets a
that the connection has already been closed by the client (e.g., the close_notify from the transport sender, it MUST reply with a
closure was indicated by TCP). close_notify unless it becomes aware that the connection has already
been closed by the transport sender (e.g., the closure was indicated
by TCP).
When no data is received from a connection for a long time (where the When no data is received from a connection for a long time (where the
application decides what "long" means), a server MAY close the application decides what "long" means), a transport receiver MAY
connection. The server MUST attempt to initiate an exchange of close the connection. The transport receiver (TLS server) MUST
close_notify alerts with the client before closing the connection. attempt to initiate an exchange of close_notify alerts with the
Servers that are unprepared to receive any more data MAY close the transport sender before closing the connection. Transport receivers
connection after sending the close_notify alert, thus generating an that are unprepared to receive any more data MAY close the connection
incomplete close on the client side. When the client has received after sending the close_notify alert, thus generating an incomplete
the close_notify alert from the server and still has pending data to close on the transport sender side.
send, it SHOULD send the pending data before sending the close_notify
alert.
5. Security Policies 5. Security Policies
Different environments have different security requirements and Different environments have different security requirements and
therefore would deploy different security policies. This section therefore would deploy different security policies. This section
discusses some of the security policies that may be implemented by discusses some of the security policies that may be implemented by
syslog transport receivers and syslog transport senders. The syslog transport receivers and syslog transport senders. The
security policies describe the requirements for authentication and security policies describe the requirements for authentication and
authorization. The list of policies in this section is not authorization. The list of policies in this section is not
exhaustive and other policies MAY be implemented. exhaustive and other policies MAY be implemented.
If the peer does not meet the requirements of the security policy, If the peer does not meet the requirements of the security policy,
the TLS handshake SHOULD be aborted with an appropriate TLS alert. the TLS handshake MUST be aborted with an appropriate TLS alert.
5.1. End-Entity Certificate Based Authorization 5.1. End-Entity Certificate Based Authorization
In the simplest case, the transport sender and receiver are In the simplest case, the transport sender and receiver are
configured with information necessary to identity the valid end- configured with information necessary to identity the valid end-
entity certificates of its authorized peers. entity certificates of its authorized peers.
Implementations MUST support specifying the authorized peers using Implementations MUST support specifying the authorized peers using
certificate fingerprints, as described in Section 4.2.1 and certificate fingerprints, as described in Section 4.2.1 and
Section 4.2.2. Section 4.2.2.
5.2. Subject Name Authorization 5.2. Subject Name Authorization
Implementations MUST support specifying the authorized peers using Implementations MUST support certification path validation [RFC5280].
locally configured host names, MUST support certification path In addition they MUST support specifying the authorized peers using
validation [RFC5280] and matching the name with the certificate as locally configured host names and matching the name against the
follows: certificate as follows.
Implementations MUST support matching the locally configured name o Implementations MUST support matching the locally configured host
against a SubjectAltName field with a type of dNSName and SHOULD name against a dNSName in the subjectAltName extension field and
support checking the name against the Common Name portion of the SHOULD support checking the name against the common name portion
Subject Distinguished Name. If more than one identity is present in of the subject distinguished name.
the certificate, a match in any one of the set is considered
acceptable. Matching of host names is case-insensitive.
Implementations also MAY support wildcards in locally configured
names to match a range of values. For example, a "*" wildcard
character MAY be used as the left-most name component. In this case,
*.example.com would match a.example.com, foo.example.com, etc., but
would not match example.com. Using a wildcard for the entire host
name makes it possible to deploy trust-root-based authorization where
all credentials issued by a particular CA trust root are authorized.
Implementations MAY also support matching a locally configured o The '*' (ASCII 42) wildcard character is allowed in the dNSName of
identifier against other parts of the certificate, such as the the subjectAltName extension (and in common name, if used to store
SerialNumber portion of the Subject Distinguished Name, or a the host name), and then only as the left-most (least significant)
SubjectAltName of type ipAddress. Implementations MAY support other DNS label in that value. This wildcard matches any left-most DNS
checks such as restrictions on the depth of a certificate chain. label in the server name. That is, the subject *.example.com
matches the server names a.example.com and b.example.com, but does
not match example.com or a.b.example.com. Implementations MUST
support wildcards in certificates as specified above, but MAY
provide a configuration option to disable them.
o Locally configured names MAY contain the wildcard character to
match a range of values. The types of wildcards supported MAY be
more flexible than that which is allowed in subject names to make
it possible to support various policies for different
environments. For example, a policy could allow for a trust-root-
based authorization where all credentials issued by a particular
CA trust root are authorized.
o If the locally configured name is an internationalized domain
name, conforming implementations MUST convert it to the ASCII
Compatible Encoding (ACE) format for performing comparisons as
specified in Section 7 of [RFC5280].
o Implementations MAY support matching a locally configured IP
address against an iPAddress stored in the subjectAltName
extension. In this case, the locally configured IP address is
converted to an octet string as specified in [RFC5280], Section
4.2.1.6. A match occurs if this octet string is equal to the
value of iPAddress in the subjectAltName extension.
5.3. Unauthenticated Transport Sender 5.3. Unauthenticated Transport Sender
In some environments, the authenticity of syslog data is not In some environments, the authenticity of syslog data is not
important or it is verifiable by other means, so transport receivers important or it is verifiable by other means, so transport receivers
may accept data from any transport sender. To achieve this, the may accept data from any transport sender. To achieve this, the
transport receiver can skip transport sender authentication (by not transport receiver can skip transport sender authentication (by not
requesting client authentication in TLS, or accepting any requesting client authentication in TLS, or accepting any
certificate). In this case, the transport receiver is authenticated certificate). In this case, the transport receiver is authenticated
and authorized, however this policy does not protect against the and authorized, however this policy does not protect against the
skipping to change at page 10, line 10 skipping to change at page 10, line 25
(by accepting any certificate). While this policy does authenticate (by accepting any certificate). While this policy does authenticate
and authorize the transport sender, it does not protect against the and authorize the transport sender, it does not protect against the
threat of transport receiver masquerade described in Section 2, threat of transport receiver masquerade described in Section 2,
leaving the data sent vulnerable to disclosure and modification. The leaving the data sent vulnerable to disclosure and modification. The
use of this policy is generally NOT RECOMMENDED for this reason. use of this policy is generally NOT RECOMMENDED for this reason.
5.5. Unauthenticated Transport Receiver and Sender 5.5. Unauthenticated Transport Receiver and Sender
In environments where security is not a concern at all, both the In environments where security is not a concern at all, both the
transport receiver and transport sender can skip authentication (as transport receiver and transport sender can skip authentication (as
described in Sections 5.2 and 5.3). This policy does not protect described in Sections 5.3 and 5.4). This policy does not protect
against any of the threats described in Section 2 and is therefore against any of the threats described in Section 2 and is therefore
NOT RECOMMENDED. NOT RECOMMENDED.
6. Security Considerations 6. Security Considerations
This section describes security considerations in addition to those This section describes security considerations in addition to those
in [I-D.ietf-tls-rfc4346-bis]. in [RFC5246].
6.1. Authentication and Authorization Policies 6.1. Authentication and Authorization Policies
Section 5 discusses various security policies that may be deployed. Section 5 discusses various security policies that may be deployed.
The threats in Section 2 are mitigated only if both the transport The threats in Section 2 are mitigated only if both the transport
sender and transport receiver are properly authenticated and sender and transport receiver are properly authenticated and
authorized, as described in Section 5.1 and Section 5.2. These are authorized, as described in Section 5.1 and Section 5.2. These are
the RECOMMENDED configurations for a default policy. the RECOMMENDED configurations for a default policy.
If the transport receiver does not authenticate the transport sender If the transport receiver does not authenticate the transport sender
skipping to change at page 11, line 26 skipping to change at page 11, line 40
retransmissions to provide protection against some forms of data retransmissions to provide protection against some forms of data
loss. However, if the TCP connection (or TLS session) is broken for loss. However, if the TCP connection (or TLS session) is broken for
some reason (or closed by the transport receiver), the syslog some reason (or closed by the transport receiver), the syslog
transport sender cannot always know what messages were successfully transport sender cannot always know what messages were successfully
delivered to the syslog application at the other end. delivered to the syslog application at the other end.
7. IANA Considerations 7. IANA Considerations
7.1. Port Number 7.1. Port Number
IANA is requested to assign a TCP port number in the range 1..1023 in IANA is requested to assign a TCP port number in the "Registered Port
the http://www.iana.org/assignments/port-numbers registry which will Numbers" range with the name "syslog-tls". This port will be the
be the default port for syslog over TLS, as defined in this document. default port for syslog over TLS, as defined in this document.
8. Acknowledgments 8. Acknowledgments
Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton
Okmianski, Balazs Scheidler, Bert Wijnen, Martin Scheutte, Chris Okmianski, Balazs Scheidler, Bert Wijnen, Martin Schuette, Chris
Lonvick and members of the syslog working group for their effort on Lonvick and members of the syslog working group for their effort on
issues resolving discussion. Authors would also like to appreciate issues resolving discussion. Authors would also like to appreciate
Balazs Scheidler, Tom Petch and other persons for their input on Balazs Scheidler, Tom Petch and other persons for their input on
security threats of syslog. The authors would like to acknowledge security threats of syslog. The authors would like to acknowledge
David Harrington for his detailed reviews of the content and grammar David Harrington for his detailed reviews of the content and grammar
of the document and Pasi Eronen for his contributions to certificate of the document and Pasi Eronen for his contributions to certificate
authentication and authorization sections. authentication and authorization sections.
9. References 9. References
skipping to change at page 12, line 16 skipping to change at page 12, line 29
September 2007. September 2007.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[I-D.ietf-tls-rfc4346-bis] [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
(TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
(work in progress), March 2008.
9.2. Informative References 9.2. Informative References
[I-D.ietf-syslog-sign] [I-D.ietf-syslog-sign]
Kelsey, J., "Signed syslog Messages", Kelsey, J., "Signed syslog Messages",
draft-ietf-syslog-sign-23 (work in progress), draft-ietf-syslog-sign-23 (work in progress),
October 2007. October 2007.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006.
Appendix A. Changes from -12 Appendix A. Changes from -12
Please remove in published RFC. Please remove in published RFC.
Section 3: Expanded note to include reference to Syslog Sign. Section 3: Expanded note to include reference to Syslog Sign.
Section 4.2: Included mandatory to implement ciphersuites that Section 4.2: Included mandatory to implement ciphersuites that
track future versions of the TLS track future versions of the TLS
Section 4.2.1: Revised to certificate based authentication Section 4.2.1: Revised to certificate based authentication
skipping to change at page 13, line 5 skipping to change at page 13, line 22
Section 5: new security policies section Section 5: new security policies section
Security Considerations: added reference to TLS security Security Considerations: added reference to TLS security
considerations, removed cipher suite section which was redundant considerations, removed cipher suite section which was redundant
with TLS with TLS
Added redundancy and name validation to security considerations Added redundancy and name validation to security considerations
section section
Appendix B. Changes from -13
Please remove in published RFC.
Section 1.1: Cleaned up definition of TLS client and TLS server
Section 4.2.2: Changed certificate fingerprint section to
reference hash registry (changed "SHA-1" to "sha-1"
Section 4.4: Clarified transport receiver and transport sender
language. Removed last sentence on sending pending data after
close.
Section 5: changed SHOULD be aborted to MUST be aborted
Section 5.2: replaced text with bullets enumerating requirements
Section 5.5: Fixed section references
Section 7.1: change IANA assignment to registered port
Section 8: Fixed the spelling of Martin's name
Authors' Addresses Authors' Addresses
Fuyou Miao (editor) Fuyou Miao (editor)
Huawei Technologies Huawei Technologies
No. 3, Xinxi Rd No. 3, Xinxi Rd
Shangdi Information Industry Base Shangdi Information Industry Base
Haidian District, Beijing 100085 Haidian District, Beijing 100085
P. R. China P. R. China
Phone: +86 10 8288 2008 Phone: +86 10 8288 2008
 End of changes. 30 change blocks. 
72 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/