target of the attack.
Note that the server may be behind a firewall or otherwise able to
access hosts that would not be directly accessible from the public
Internet. This could exacerbate the potential security and denial of
service problems described above, as well as allow the existence of
internal hosts to be confirmed when they would otherwise be hidden.
The detailed security concerns involved will depend on the URL
schemes supported by the server. In the case of HTTP, the concerns
are similar to those that apply to a publicly accessible HTTP proxy
server. In the case of HTTPS, loops and deadlocks may be created,
and this should be addressed. In the case of FTP, attacks arise that
are similar to FTP bounce attacks.
As a result of this issue, it is RECOMMENDED that the
client_certificate_url extension should have to be specifically
enabled by a server administrator, rather than be enabled by default.
It is also RECOMMENDED that URI protocols be enabled by the
administrator individually, and only a minimal set of protocols be
enabled. Unusual protocols that offer limited security or whose
security is not well-understood SHOULD be avoided.
As discussed in [URI], URLs that specify ports other than the default
may cause problems, as may very long URLs (which are more likely to
be useful in exploiting buffer overflow bugs).
Also note that HTTP caching proxies are common on the Internet, and
some proxies do not check for the latest version of an object
correctly. If a request using HTTP (or another caching protocol)
goes through a misconfigured or otherwise broken proxy, the proxy may
return an out-of-date response.
6.4. Security of trusted_ca_keys
It is possible that which CA root keys a client possesses could be
regarded as confidential information. As a result, the CA root key
indication extension should be used with care.
The use of the SHA-1 certificate hash alternative ensures that each
certificate is specified unambiguously. As for the previous
extension, it was not believed necessary to use both MD5 and SHA-1
hashes.
6.5. Security of truncated_hmac
It is possible that truncated MACs are weaker than "un-truncated"
MACs. However, no significant weaknesses are currently known or
expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
Note that the output length of a MAC need not be as long as the
length of a symmetric cipher key, since forging of MAC values cannot
be done off-line: in TLS, a single failed MAC guess will cause the
immediate termination of the TLS session.
Since the MAC algorithm only takes effect after all handshake
messages that affect extension parameters have been authenticated by
the hashes in the Finished messages, it is not possible for an active
attacker to force negotiation of the truncated HMAC extension where
it would not otherwise be used (to the extent that the handshake
authentication is secure). Therefore, in the event that any security
problem were found with truncated HMAC in the future, if either the
client or the server for a given session were updated to take the
problem into account, it would be able to veto use of this extension.
6.6. Security of status_request
If a client requests an OCSP response, it must take into account that
an attacker’s server using a compromised key could (and probably
would) pretend not to support the extension. In this case, a client
that requires OCSP validation of certificates SHOULD either contact
the OCSP server directly or abort the handshake.
Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
improve security against attacks that attempt to replay OCSP
responses; see Section 4.4.1 of [OCSP] for further details.
7. Internationalization Considerations
None of the extensions defined here directly use strings subject to
localization. Domain Name System (DNS) hostnames are encoded using
UTF-8. If future extensions use text strings, then
internationalization should be considered in their design.
8. IANA Considerations
Sections 2.3 and 5 describe a registry of ExtensionType values to be
maintained by the IANA. ExtensionType values are to be assigned via
IETF Consensus as defined in RFC 2434 [IANA]. The initial registry
corresponds to the definition of "ExtensionType" in Section 2.3.
The MIME type "application/pkix-pkipath" has been registered by the
IANA with the following template:
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkix-pkipath
MIME media type name: application
MIME subtype name: pkix-pkipath
Required parameters: none
Optional parameters: version (default value is "1")
Encoding considerations:
This MIME type is a DER encoding of the ASN.1 type PkiPath,
defined as follows:
PkiPath ::= SEQUENCE OF Certificate
PkiPath is used to represent a certification path. Within the
sequence, the order of certificates is such that the subject of
the first certificate is the issuer of the second certificate,
etc.
This is identical to the definition published in [X509-4th-TC1];
note that it is different from that in [X509-4th].
All Certificates MUST conform to [PKIX]. (This should be
interpreted as a requirement to encode only PKIX-conformant
certificates using this type. It does not necessarily require
that all certificates that are not strictly PKIX-conformant must
be rejected by relying parties, although the security consequences
of accepting any such certificates should be considered
carefully.)
DER (as opposed to BER) encoding MUST be used. If this type is
sent over a 7-bit transport, base64 encoding SHOULD be used.
Security considerations:
The security considerations of [X509-4th] and [PKIX] (or any
updates to them) apply, as well as those of any protocol that uses
this type (e.g., TLS).
Note that this type only specifies a certificate chain that can be
assessed for validity according to the relying party’s existing
configuration of trusted CAs; it is not intended to be used to
specify any change to that configuration.
Interoperability considerations:
No specific interoperability problems are known with this type,
but for recommendations relating to X.509 certificates in general,
see [PKIX].
Published specification: RFC 4366 (this memo), and [PKIX].
Applications which use this media type: TLS. It may also be used by
other protocols, or for general interchange of PKIX certificate
chains.
Additional information:
Magic number(s): DER-encoded ASN.1 can be easily recognized.
Further parsing is required to distinguish it from other ASN.1
types.
File extension(s): .pkipath
Macintosh File Type Code(s): not specified
Person & email address to contact for further information:
Magnus Nystrom <magnus@rsasecurity.com>
Intended usage: COMMON
Change controller:
IESG <iesg@ietf.org>
9. Acknowledgements
The authors wish to thank the TLS Working Group and the WAP Security
Group. This document is based on discussion within these groups.
10. Normative References
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
June 1999.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[IDNA] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
C. Adams, "X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP", RFC 2560,
June 1999.
[PKIOP] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999.
[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo,
"Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC
3280, April 2002.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[TLSbis] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC
9594-8:2001, "Information Systems - Open Systems
Interconnection - The Directory: Public key and
attribute certificate frameworks."
[X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum
1 to ISO/IEC 9594:8:2001.
11. Informative References
[AESSUITES] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 2002.
[KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999.
[MAILINGLIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General
ClientHello extension mechanism and virtual hosting,"
ietf-tls mailing list posting, August 14, 2000.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
J., and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
Authors’ Addresses
Simon Blake-Wilson
BCI
EMail: sblakewilson@bcisse.com
Magnus Nystrom
RSA Security
EMail: magnus@rsasecurity.com
David Hopwood
Independent Consultant
EMail: david.hopwood@blueyonder.co.uk
Jan Mikkelsen
Transactionware
EMail: janm@transactionware.com
Tim Wright
Vodafone
EMail: timothy.wright@vodafone.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).