Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses
RFC 6432

Document	Type	RFC - Proposed Standard (November 2011) Was draft-jesske-dispatch-update3326-reason-responses (individual in rai area)
	Authors	Laura Liess , Roland Jesske
	Last updated	2015-10-14
	RFC stream	Internet Engineering Task Force (IETF)
	Formats	txt html pdf htmlized bibtex
IESG	Responsible AD	Gonzalo Camarillo
	Send notices to	(None)

Email authors IPR References Referenced by Search Lists

RFC 6432

Internet Engineering Task Force (IETF) R. Jesske
Request for Comments: 6432 L. Liess
Category: Standards Track Deutsche Telekom
ISSN: 2070-1721 November 2011

Carrying Q.850 Codes in Reason Header Fields
in SIP (Session Initiation Protocol) Responses

Abstract

Although the use of the SIP (Session Initiation Protocol) Reason
header field in responses is considered in general in RFC 3326, its
use is not specified for any particular response code. Nonetheless,
existing deployments have been using Reason header fields to carry
failure-related Q.850 cause codes in SIP responses to INVITE requests
that have been gatewayed to Public Switched Telephone Network (PSTN)
systems. This document normatively describes the use of the Reason
header field in carrying Q.850 cause codes in SIP responses.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6432.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Jesske & Liess Standards Track [Page 1]
RFC 6432 Reason Header Field November 2011

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

Table of Contents

1. Overview ........................................................2
2. Terminology .....................................................2
3. Applicability ...................................................3
4. Security Considerations .........................................3
5. Acknowledgments .................................................3
6. Normative References ............................................3

1. Overview

Although the use of the SIP (Session Initiation Protocol) Reason
header field in responses is considered in general in RFC 3326
[RFC3326], its use is not specified for any particular response code.
Nonetheless, existing deployments have been using Reason header
fields to carry failure-related Q.850 [Q.850] cause codes in SIP
responses to INVITE requests that have been gatewayed to PSTN
systems. This document normatively describes the use of the Reason
header field in SIP responses to carry Q.850 [Q.850] cause codes.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

This document uses terms from [RFC3261].

Jesske & Liess Standards Track [Page 2]
RFC 6432 Reason Header Field November 2011

3. Applicability

This document allows SIP responses to carry Reason header fields as
follows:

Any SIP Response message, with the exception of a 100 (Trying),
MAY contain a Reason header field with a Q.850 [Q.850] cause code.

The Reason header field is not needed in the 100 (Trying)
responses, since they are transmitted hop by hop, not end to end.
SIP responses with Reason header fields carrying values other than
Q.850 [Q.850] cause codes are outside of the scope of this
document.

4. Security Considerations

This specification allows the presence of the Reason header field
containing Q.850 [Q.850] cause codes in responses. The presence of
the Reason header field in a response does not affect the treatment
of the response. Nevertheless, there could be situations where a
wrong Q.850 [Q.850] cause code could, for example, cause an
announcement system to play the wrong information. To avoid such
situations, it is RECOMMENDED that this header field be protected by
a suitable integrity mechanism. The use of transport- or network-
layer hop-by-hop security mechanisms, such as Transport Layer
Security (TLS) or IPsec with appropriate cipher suites, can satisfy
this requirement.

5. Acknowledgments

Thanks to Gonzalo Camarillo and Mary Barnes for the detailed review
of this document.

Thanks to Paul Kyzivat, Mary Barnes, John Elwell, Keith Drage, and
Thomas Belling, who provided helpful comments, feedback, and
suggestions.

6. Normative References

[Q.850] "Usage of cause and location in the Digital Subscriber
Signalling System No. 1 and the Signalling System No. 7
ISDN User Part", ITU Recommendation Q.850, May 1998.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

quot;
format is defined in Section 4.2. In TLS 1.3, use of certain
extensions is mandatory, as functionality is moved into extensions
to preserve ClientHello compatibility with previous versions of
TLS. Servers MUST ignore unrecognized extensions.

All versions of TLS allow an extensions field to optionally follow
the compression_methods field. TLS 1.3 ClientHello messages always
contain extensions (minimally "supported_versions", otherwise they
will be interpreted as TLS 1.2 ClientHello messages). However, TLS
1.3 servers might receive ClientHello messages without an extensions
field from prior versions of TLS. The presence of extensions can be
detected by determining whether there are bytes following the
compression_methods field at the end of the ClientHello. Note that
this method of detecting optional data differs from the normal TLS
method of having a variable-length field, but it is used for
compatibility with TLS before extensions were defined. TLS 1.3
servers will need to perform this check first and only attempt to
negotiate TLS 1.3 if a "supported_version" extension is present. If
negotiating a version of TLS prior to 1.3, a server MUST check that
the message either contains no data after legacy_compression_methods
or that it contains a valid extensions block with no data following.
If not, then it MUST abort the handshake with a "decode_error" alert.

In the event that a client requests additional functionality using
extensions, and this functionality is not supplied by the server, the
client MAY abort the handshake.

After sending the ClientHello message, the client waits for a
ServerHello or HelloRetryRequest message. If early data is in use,
the client may transmit early application data Section 2.3 while
waiting for the next handshake message.

Rescorla Expires January 4, 2018 [Page 33]
Internet-Draft TLS July 2017

4.1.3. Server Hello

The server will send this message in response to a ClientHello
message to proceed with the handshake if it is able to negotiate an
acceptable set of handshake parameters based on the ClientHello.

Structure of this message:

struct {
ProtocolVersion version;
Random random;
CipherSuite cipher_suite;
Extension extensions<6..2^16-1>;
} ServerHello;

version This field contains the version of TLS negotiated for this
connection. Servers MUST select a version from the list in
ClientHello's supported_versions extension, or otherwise negotiate
TLS 1.2 or previous. A client that receives a version that was
not offered MUST abort the handshake. For this version of the
specification, the version is 0x0304. (See Appendix D for details
about backward compatibility.)

random 32 bytes generated by a secure random number generator. See
Appendix C for additional information. The last eight bytes MUST
be overwritten as described below if negotiating TLS 1.2 or TLS
1.1, but the remaining bytes MUST be random. This structure is
generated by the server and MUST be generated independently of the
ClientHello.random.

cipher_suite The single cipher suite selected by the server from the
list in ClientHello.cipher_suites. A client which receives a
cipher suite that was not offered MUST abort the handshake with an
"illegal_parameter" alert.

extensions A list of extensions. The ServerHello MUST only include
extensions which are required to establish the cryptographic
context. Currently the only such extensions are "key_share" and
"pre_shared_key". All current TLS 1.3 ServerHello messages will
contain one of these two extensions, or both when using a PSK with
(EC)DHE key establishment. The remaining extensions are sent
separately in the EncryptedExtensions message.

TLS 1.3 has a downgrade protection mechanism embedded in the server's
random value. TLS 1.3 servers which negotiate TLS 1.2 or below in
response to a ClientHello MUST set the last eight bytes of their
Random value specially.

Rescorla Expires January 4, 2018 [Page 34]
Internet-Draft TLS July 2017

If negotiating TLS 1.2, TLS 1.3 servers MUST set the last eight bytes
of their Random value to the bytes:

44 4F 57 4E 47 52 44 01

If negotiating TLS 1.1 or below, TLS 1.3 servers MUST and TLS 1.2
servers SHOULD set the last eight bytes of their Random value to the
bytes:

44 4F 57 4E 47 52 44 00

TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below
MUST check that the last eight bytes are not equal to either of these
values. TLS 1.2 clients SHOULD also check that the last eight bytes
are not equal to the second value if the ServerHello indicates TLS
1.1 or below. If a match is found, the client MUST abort the
handshake with an "illegal_parameter" alert. This mechanism provides
limited protection against downgrade attacks over and above what is
provided by the Finished exchange: because the ServerKeyExchange, a
message present in TLS 1.2 and below, includes a signature over both
random values, it is not possible for an active attacker to modify
the random values without detection as long as ephemeral ciphers are
used. It does not provide downgrade protection when static RSA is
used.

Note: This is a change from [RFC5246], so in practice many TLS 1.2
clients and servers will not behave as specified above.

A legacy TLS client performing renegotiation with TLS 1.2 or prior
and which receives a TLS 1.3 ServerHello during renegotiation MUST
abort the handshake with a "protocol_version" alert. Note that
renegotiation is not possible when TLS 1.3 has been negotiated.

RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of
draft versions (see Section 4.2.1.1) of this specification SHOULD NOT
implement this mechanism on either client and server. A pre-RFC
client connecting to RFC servers, or vice versa, will appear to
downgrade to TLS 1.2. With the mechanism enabled, this will cause an
interoperability failure.

4.1.4. Hello Retry Request

The server will send this message in response to a ClientHello
message if it is able to find an acceptable set of parameters but the
ClientHello does not contain sufficient information to proceed with
the handshake.

Structure of this message:

Rescorla Expires January 4, 2018 [Page 35]
Internet-Draft TLS July 2017

struct {
ProtocolVersion server_version;
CipherSuite cipher_suite;
Extension extensions<2..2^16-1>;
} HelloRetryRequest;

The version, cipher_suite, and extensions fields have the same
meanings as their corresponding values in the ServerHello. The
server SHOULD send only the extensions necessary for the client to
generate a correct ClientHello pair. As with ServerHello, a
HelloRetryRequest MUST NOT contain any extensions that were not first
offered by the client in its ClientHello, with the exception of
optionally the "cookie" (see Section 4.2.2) extension.

Upon receipt of a HelloRetryRequest, the client MUST verify that the
extensions block is not empty and otherwise MUST abort the handshake
with a "decode_error" alert. Clients MUST abort the handshake with
an "illegal_parameter" alert if the HelloRetryRequest would not
result in any change in the ClientHello. If a client receives a
second HelloRetryRequest in the same connection (i.e., where the
ClientHello was itself in response to a HelloRetryRequest), it MUST
abort the handshake with an "unexpected_message" alert.

Otherwise, the client MUST process all extensions in the
HelloRetryRequest and send a second updated ClientHello. The
HelloRetryRequest extensions defined in this specification are:

- cookie (see Section 4.2.2)

- key_share (see Section 4.2.7)

In addition, in its updated ClientHello, the client SHOULD NOT offer
any pre-shared keys associated with a hash other than that of the
selected cipher suite. This allows the client to avoid having to
compute partial hash transcripts for multiple hashes in the second
ClientHello. A client which receives a cipher suite that was not
offered MUST abort the handshake. Servers MUST ensure that they
negotiate the same cipher suite when receiving a conformant updated
ClientHello (if the server selects the cipher suite as the first step
in the negotiation, then this will happen automatically). Upon
receiving the ServerHello, clients MUST check that the cipher suite
supplied in the ServerHello is the same as that in the
HelloRetryRequest and otherwise abort the handshake with an
"illegal_parameter" alert.

Rescorla Expires January 4, 2018 [Page 36]
Internet-Draft TLS July 2017

4.2. Extensions

A number of TLS messages contain tag-length-value encoded extensions
structures.

struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;

enum {
server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 4492, 7919 */
signature_algorithms(13), /* RFC 5246 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
key_share(40), /* [[this document]] */
pre_shared_key(41), /* [[this document]] */
early_data(42), /* [[this document]] */
supported_versions(43), /* [[this document]] */
cookie(44), /* [[this document]] */
psk_key_exchange_modes(45), /* [[this document]] */
certificate_authorities(47), /* [[this document]] */
oid_filters(48), /* [[this document]] */
post_handshake_auth(49), /* [[this document]] */
(65535)
} ExtensionType;

Here:

- "extension_type" identifies the particular extension type.

- "extension_data" contains information specific to the particular
extension type.

The list of extension types is maintained by IANA as described in
Section 11.

Extensions are generally structured in a request/response fashion,
though some extensions are just indications with no corresponding
response. The client sends its extension requests in the ClientHello

Rescorla Expires January 4, 2018 [Page 37]
Internet-Draft TLS July 2017

message and the server sends its extension responses in the
ServerHello, EncryptedExtensions, HelloRetryRequest and Certificate
messages. The server sends extension requests in the
CertificateRequest message which a client MAY respond to with a
Certificate message. The server MAY also send unsolicited extensions
in the NewSessionTicket, though the client does not respond directly
to these.

Implementations MUST NOT send extension responses if the remote
endpoint did not send the corresponding extension requests, with the
exception of the "cookie" extension in HelloRetryRequest. Upon
receiving such an extension, an endpoint MUST abort the handshake
with an "unsupported_extension" alert.

The table below indicates the messages where a given extension may
appear, using the following notation: CH (ClientHello), SH
(ServerHello), EE (EncryptedExtensions), CT (Certificate), CR
(CertificateRequest), NST (NewSessionTicket) and HRR
(HelloRetryRequest). If an implementation receives an extension
which it recognizes and which is not specified for the message in
which it appears it MUST abort the handshake with an
"illegal_parameter" alert.

Rescorla Expires January 4, 2018 [Page 38]
Internet-Draft TLS July 2017

When multiple extensions of different types are present, the
extensions MAY appear in any order, with the exception of

Rescorla Expires January 4, 2018 [Page 39]
Internet-Draft TLS July 2017

"pre_shared_key" Section 4.2.10 which MUST be the last extension in
the ClientHello. There MUST NOT be more than one extension of the
same type in a given extension block.

In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each
handshake even when in resumption-PSK mode. However, 0-RTT
parameters are those negotiated in the previous handshake; mismatches
may require rejecting 0-RTT (see Section 4.2.9).

There are subtle (and not so subtle) interactions that may occur in
this protocol between new features and existing features which may
result in a significant reduction in overall security. The following
considerations should be taken into account when designing new
extensions:

- Some cases where a server does not agree to an extension are error
conditions, and some are simply refusals to support particular
features. In general, error alerts should be used for the former
and a field in the server extension response for the latter.

- Extensions should, as far as possible, be designed to prevent any
attack that forces use (or non-use) of a particular feature by
manipulation of handshake messages. This principle should be
followed regardless of whether the feature is believed to cause a
security problem. Often the fact that the extension fields are
included in the inputs to the Finished message hashes will be
sufficient, but extreme care is needed when the extension changes
the meaning of messages sent in the handshake phase. Designers
and implementors should be aware of the fact that until the
handshake has been authenticated, active attackers can modify
messages and insert, remove, or replace extensions.

4.2.1. Supported Versions

struct {
ProtocolVersion versions<2..254>;
} SupportedVersions;

The "supported_versions" extension is used by the client to indicate
which versions of TLS it supports. The extension contains a list of
supported versions in preference order, with the most preferred
version first. Implementations of this specification MUST send this
extension containing all versions of TLS which they are prepared to
negotiate (for this specification, that means minimally 0x0304, but
if previous versions of TLS are allowed to be negotiated, they MUST
be present as well).

Rescorla Expires January 4, 2018 [Page 40]
Internet-Draft TLS July 2017

If this extension is not present, servers which are compliant with
this specification MUST negotiate TLS 1.2 or prior as specified in
[RFC5246], even if ClientHello.legacy_version is 0x0304 or later.
Servers MAY abort the handshake upon receiving a ClientHello with
legacy_version 0x0304 or later.

If this extension is present, servers MUST ignore the
ClientHello.legacy_version value and MUST use only the
"supported_versions" extension to determine client preferences.
Servers MUST only select a version of TLS present in that extension
and MUST ignore any unknown versions that are present in that
extension. Note that this mechanism makes it possible to negotiate a
version prior to TLS 1.2 if one side supports a sparse range.
Implementations of TLS 1.3 which choose to support prior versions of
TLS SHOULD support TLS 1.2. Servers should be prepared to receive
ClientHellos that include this extension but do not include 0x0304 in
the list of versions.

The server MUST NOT send the "supported_versions" extension. The
server's selected version is contained in the ServerHello.version
field as in previous versions of TLS.

4.2.1.1. Draft Version Indicator

RFC EDITOR: PLEASE REMOVE THIS SECTION

While the eventual version indicator for the RFC version of TLS 1.3
will be 0x0304, implementations of draft versions of this
specification SHOULD instead advertise 0x7f00 | draft_version in
ServerHello.version, and HelloRetryRequest.server_version. For
instance, draft-17 would be encoded as the 0x7f11. This allows pre-
RFC implementations to safely negotiate with each other, even if they
would otherwise be incompatible.

4.2.2. Cookie

struct {
opaque cookie<1..2^16-1>;
} Cookie;

Cookies serve two primary purposes:

- Allowing the server to force the client to demonstrate
reachability at their apparent network address (thus providing a
measure of DoS protection). This is primarily useful for non-
connection-oriented transports (see [RFC6347] for an example of
this).

Rescorla Expires January 4, 2018 [Page 41]
Internet-Draft TLS July 2017

- Allowing the server to offload state to the client, thus allowing
it to send a HelloRetryRequest without storing any state. The
server can do this by storing the hash of the ClientHello in the
HelloRetryRequest cookie (protected with some suitable integrity
algorithm).

When sending a HelloRetryRequest, the server MAY provide a "cookie"
extension to the client (this is an exception to the usual rule that
the only extensions that may be sent are those that appear in the
ClientHello). When sending the new ClientHello, the client MUST copy
the contents of the extension received in the HelloRetryRequest into
a "cookie" extension in the new ClientHello. Clients MUST NOT use
cookies in subsequent connections.

4.2.3. Signature Algorithms

The client uses the "signature_algorithms" extension to indicate to
the server which signature algorithms may be used in digital
signatures. Clients which desire the server to authenticate itself
via a certificate MUST send this extension. If a server is
authenticating via a certificate and the client has not sent a
"signature_algorithms" extension, then the server MUST abort the
handshake with a "missing_extension" alert (see Section 9.2).

The "extension_data" field of this extension in a ClientHello
contains a SignatureSchemeList value:

Rescorla Expires January 4, 2018 [Page 42]
Internet-Draft TLS July 2017

enum {
/* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha256(0x0401),
rsa_pkcs1_sha384(0x0501),
rsa_pkcs1_sha512(0x0601),

/* ECDSA algorithms */
ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603),

/* RSASSA-PSS algorithms */
rsa_pss_sha256(0x0804),
rsa_pss_sha384(0x0805),
rsa_pss_sha512(0x0806),

/* EdDSA algorithms */
ed25519(0x0807),
ed448(0x0808),

/* Legacy algorithms */
rsa_pkcs1_sha1(0x0201),
ecdsa_sha1(0x0203),

/* Reserved Code Points */
private_use(0xFE00..0xFFFF),
(0xFFFF)
} SignatureScheme;

struct {
SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList;

Note: This enum is named "SignatureScheme" because there is already a
"SignatureAlgorithm" type in TLS 1.2, which this replaces. We use
the term "signature algorithm" throughout the text.

Each SignatureScheme value lists a single signature algorithm that
the client is willing to verify. The values are indicated in
descending order of preference. Note that a signature algorithm
takes as input an arbitrary-length message, rather than a digest.
Algorithms which traditionally act on a digest should be defined in
TLS to first hash the input with a specified hash algorithm and then
proceed as usual. The code point groups listed above have the
following meanings:

RSASSA-PKCS1-v1_5 algorithms Indicates a signature algorithm using
RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm

Rescorla Expires January 4, 2018 [Page 43]
Internet-Draft TLS July 2017

as defined in [SHS]. These values refer solely to signatures
which appear in certificates (see Section 4.4.2.2) and are not
defined for use in signed TLS handshake messages.

ECDSA algorithms Indicates a signature algorithm using ECDSA
[ECDSA], the corresponding curve as defined in ANSI X9.62 [X962]
and FIPS 186-4 [DSS], and the corresponding hash algorithm as
defined in [SHS]. The signature is represented as a DER-encoded
[X690] ECDSA-Sig-Value structure.

RSASSA-PSS algorithms Indicates a signature algorithm using RSASSA-
PSS [RFC8017] with mask generation function 1. The digest used in
the mask generation function and the digest being signed are both
the corresponding hash algorithm as defined in [SHS]. When used
in signed TLS handshake messages, the length of the salt MUST be
equal to the length of the digest output. This codepoint is new
in this document and is also defined for use with TLS 1.2.

EdDSA algorithms Indicates a signature algorithm using EdDSA as
defined in [RFC8032] or its successors. Note that these
correspond to the "PureEdDSA" algorithms and not the "prehash"
variants.

Legacy algorithms Indicates algorithms which are being deprecated
because they use algorithms with known weaknesses, specifically
SHA-1 which is used in this context with either with RSA using
RSASSA-PKCS1-v1_5 or ECDSA. These values refer solely to
signatures which appear in certificates (see Section 4.4.2.2) and
are not defined for use in signed TLS handshake messages.
Endpoints SHOULD NOT negotiate these algorithms but are permitted
to do so solely for backward compatibility. Clients offering
these values MUST list them as the lowest priority (listed after
all other algorithms in SignatureSchemeList). TLS 1.3 servers
MUST NOT offer a SHA-1 signed certificate unless no valid
certificate chain can be produced without it (see
Section 4.4.2.2).

The signatures on certificates that are self-signed or certificates
that are trust anchors are not validated since they begin a
certification path (see [RFC5280], Section 3.2). A certificate that
begins a certification path MAY use a signature algorithm that is not
advertised as being supported in the "signature_algorithms"
extension.

Note that TLS 1.2 defines this extension differently. TLS 1.3
implementations willing to negotiate TLS 1.2 MUST behave in
accordance with the requirements of [RFC5246] when negotiating that
version. In particular:

Rescorla Expires January 4, 2018 [Page 44]
Internet-Draft TLS July 2017

- TLS 1.2 ClientHellos MAY omit this extension.

- In TLS 1.2, the extension contained hash/signature pairs. The
pairs are encoded in two octets, so SignatureScheme values have
been allocated to align with TLS 1.2's encoding. Some legacy
pairs are left unallocated. These algorithms are deprecated as of
TLS 1.3. They MUST NOT be offered or negotiated by any
implementation. In particular, MD5 [SLOTH], SHA-224, and DSA MUST
NOT be used.

- ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature
pairs. However, the old semantics did not constrain the signing
curve. If TLS 1.2 is negotiated, implementations MUST be prepared
to accept a signature that uses any curve that they advertised in
the "supported_groups" extension.

- Implementations that advertise support for RSASSA-PSS (which is
mandatory in TLS 1.3), MUST be prepared to accept a signature
using that scheme even when TLS 1.2 is negotiated. In TLS 1.2,
RSASSA-PSS is used with RSA cipher suites.

4.2.4. Certificate Authorities

The "certificate_authorities" extension is used to indicate the
certificate authorities which an endpoint supports and which SHOULD
be used by the receiving endpoint to guide certificate selection.

The body of the "certificate_authorities" extension consists of a
CertificateAuthoritiesExtension structure.

opaque DistinguishedName<1..2^16-1>;

struct {
DistinguishedName authorities<3..2^16-1>;
} CertificateAuthoritiesExtension;

authorities A list of the distinguished names [X501] of acceptable
certificate authorities, represented in DER-encoded [X690] format.
These distinguished names specify a desired distinguished name for
trust anchor or subordinate CA; thus, this message can be used to
describe known trust anchors as well as a desired authorization
space.

The client MAY send the "certificate_authorities" extension in the
ClientHello message. The server MAY send it in the
CertificateRequest message.

Rescorla Expires January 4, 2018 [Page 45]
Internet-Draft TLS July 2017Jesske & Liess Standards Track [Page 3]
RFC 6432 Reason Header Field November 2011

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.

[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002.

Authors' Addresses

Roland Jesske
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt 64307
Germany

Phone: +4961515812766
EMail: r.jesske@telekom.de

Laura Liess
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt 64307
Germany

Phone: +4961515812761
EMail: L.Liess@telekom.de

Jesske & Liess Standards Track [Page 4]

Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses RFC 6432

Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses
RFC 6432