Internet DRAFT - draft-thomson-mmusic-fingerprint
draft-thomson-mmusic-fingerprint
MMUSIC M. Thomson
Internet-Draft Microsoft
Updates: 4572 (if approved) October 22, 2013
Intended status: Standards Track
Expires: April 25, 2014
Use of Fingerprints for Identifying Certificates in the Session
Description Protocol (SDP)
draft-thomson-mmusic-fingerprint-00
Abstract
The Session Description Protocol (SDP) fingerprint attribute binds a
session description to an X.509 certificate. This document describes
how hash agility is achieved without backwards compatibility issues.
This document also describes how the fingerprint attribute can be
used to identify a set of valid certificates.
This document updates RFC4572.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Thomson Expires April 25, 2014 [Page 1]
Internet-Draft SDP Certificate Fingerprints October 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3
2. Hash Agility . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Multiple Certificates . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
RFC 4572 [RFC4572] describes how the fingerprint Session Description
Protocol (SDP) [RFC4566] attribute binds a session description to an
X.509 certificate [X509]. Unfortunately, the only statement it makes
regarding multiple fingerprints is the following:
A certificate fingerprint MUST be computed using the same one-way
hash function as is used in the certificate's signature algorithm.
This has the unfortunate consequence of unnecessarily coupling the
security properties of the certificate to the hash function used in
signing the certificate. To maximize the chances of a certificate
being accepted, the hash algorithm used in certificates tends to lag
current best practice, potentially exposing sessions to attacks based
on hash collision.
The ability to use stronger cryptographic hash algorithms (hash
agility) improves the integrity of the binding between the session
description and the entity in possession of the private key. Systems
that rely on other bindings to the session (or the private keys used
to establish it) do not benefit from these changes.
This document also describes an optional mechanism that might be used
to identify multiple certificates, in cases where the offered
certificate might be selected from a small set. This might have
operational advantages where the endpoint answering a call is not
known ahead of a session description being created.
Thomson Expires April 25, 2014 [Page 2]
Internet-Draft SDP Certificate Fingerprints October 2013
1.1. Conventions and Terminology
At times, this document falls back on shorthands for establishing
interoperability requirements on implementations: the capitalized
words "MUST", "SHOULD" and "MAY". These terms are defined in
[RFC2119].
2. Hash Agility
The SDP fingerprint attribute is used to indicate the hash of the
certificate - a certificate fingerprint - that is offered in the TLS
[RFC5246] or DTLS [RFC5764] handshake. The certificate fingerprint
so included is used to bind the (D)TLS session to the session
description.
Multiple fingerprint attributes can be used to identify a certificate
using alternative cryptographic hash algorithms. This allows
sessions descriptions to use alternative, potentially stronger, hash
algorithms without risking interoperability failure. A stronger hash
algorithm is more resistant to collision attacks, which can be used
to impersonate endpoints.
To avoid cases where certificate fingerprints cannot be validated,
implementations MUST support SHA-256 [FIPS2]. That is, a fingerprint
attribute using SHA-256 MUST be included in any place that includes
fingerprint attributes and implementations MUST be able to validate
SHA-256 fingerprints.
Implementations or specific applications can specify that validation
using a different hash algorithm be mandatory in order to achieve a
desired level of collision resistance. Implementations MUST NOT
consider a session binding to be valid unless a certificate
fingerprint using sufficiently strong hash algorithm matches one in
the session description. For example, an application might specify
that certificates are validated using SHA-384 [FIPS2] in addition to,
or instead of, SHA-256.
Additional fingerprint attributes MAY be included using alternative
hash algorithms. An endpoint that validates a session using
fingerprint attributes MUST report failure if any hash that it checks
doesn't match.
Endpoints can ignore fingerprint attributes that use hash algorithms
it doesn't support or wish to validate.
3. Multiple Certificates
Thomson Expires April 25, 2014 [Page 3]
Internet-Draft SDP Certificate Fingerprints October 2013
It might be that an application desires the ability to create session
descriptions where the security context can be terminated using one
of a small set of certificates.
An endpoint that validates a session description with multiple values
for the same hash algorithm MUST fail the validation unless a
fingerprint matches for each hash algorithm validated. Therefore, a
session description that includes multiple a=fingerprint values for
the same hash algorithm MUST include the same number of a=fingerprint
values for every hash algorithm that is included.
4. Security Considerations
Over time, advances in cryptanalysis and computational power render
hash algorithms increasingly prone to collision attacks. A hash
collision on a certificate fingerprint would allow for impersonation.
This document describes how to use different hash algorithms,
independent of those selected for use in certificates.
Hash agility does not reduce the need for session description
integrity protection or any of the suggested supporting mechanisms
described in [RFC4572].
Adding support for hash agility does not affect the properties gained
through the use of other mechanisms like the use of other bindings
between session and identity. This document only improves the
binding between a session and its description in SDP. For example,
mechanisms such as the one described in
[I-D.ietf-rtcweb-security-arch] require the implementation of
equivalent processing rules to benefit from hash agility. Systems
relying on the X.509 certificate chain to a specific trust anchor are
similarly unaffected.
5. IANA Considerations
This document has no IANA actions.
6. Acknowledgements
Kevin Dempsey raised the original question that motivated this draft.
7. References
Thomson Expires April 25, 2014 [Page 4]
Internet-Draft SDP Certificate Fingerprints October 2013
7.1. Normative References
[FIPS2] , "Secure Hash Standard ", FIPS PUB 180-2, ISO Standard
9594-8, August 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[X509] , "Information technology - Open Systems Interconnection -
The Directory: Public-key and attribute certificate
frameworks ", ITU-T Recommendation X.509, ISO Standard
9594-8, March 2000.
7.2. Informative References
[I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-07 (work in progress), July 2013.
Author's Address
Martin Thomson
Microsoft
3210 Porter Drive
Palo Alto, CA 94304
US
Email: martin.thomson@skype.net
Thomson Expires April 25, 2014 [Page 5]
