GROUPE DES ECOLES DES TELECOMMUNICATIONS - ECOLE NATIONALE SUPERIEURE DES TELECOMMUNICATIONS 's General License Statement
Only those sections of the "Patent Disclosure and Licensing Declaration Template for Generic IPR Disclosures" where the submitter provided information are displayed.
Click here to update this IPR disclosure
Submitted Date: December 17, 2008
I. Patent Holder/Applicant ("Patent Holder") Legal Name: GROUPE DES ECOLES DES TELECOMMUNICATIONS - ECOLE NATIONALE SUPERIEURE DES TELECOMMUNICATIONS
II. Patent Holder's Contact for License Application Name: GROUPE DES ECOLES DES TELECOMMUNICATIONS - ECOLE NATIONALE SUPERIEURE DES TELECOMMUNICATIONS Title: Department: Address1: Address2: Telephone: 0033145817777 Fax: 0033145897906 Email: contact@enst.fr
III. Disclosure of Patent Information (i.e., patents or patent applications required to be disclosed by Section 6 of RFC 3979) A. For granted patents or published pending patent applications, please provide the following information: Patent, Serial, Publication, Registration, or Application/File number(s): WO/2007/115982 PCT/EP2007/053268 Date(s) granted or applied for: 03.04.2007 Country: France Additional Notes: With regards to the IPR disclosure available at
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=1036,
the authors of that draft believe that there is no claims to do with
regards to the patent; each of these two documents describes its own
way to negotiate the identity protection during the TLS negotiation
(the draft enables that by defining a set of specific TLS Cipher
Suites, whereas the patent proposes specifying a new TLS extension
for that purpose).Computing a key from the premaster secret and the random values using
the PRF function isn't patentable, since this is specified by TLS and
SSL documents. From the authors' point of view, the way for the
client and the server to negotiate the identity protection feature is
the only part to be patentable. This is why the authors estimated
that no IPR disclosure is required. On the other hand, the draft
authors - one of them is also a co-inventor of the patent - already
discussed of this situation with the involved entity during the draft
revision process and explained their point of view regarding the
relationship between the draft - which is not aiming at Standards
Track - and the patent. Moreover, they proposed sending at that time
an IPR disclosure, if needed.In any case, the way for encrypting the certificate during key
exchange protocols (i.e., TLS) is not new and had been said many
times before the patent publication date. Below some non-exclusive
publications that enable identity protection by asymmetrically or
symmetrically encrypting the certificate using a secret key computed
during the key exchange establishment. Some of them compute the key
to encrypt the certificate, in the same way as the patent proposes
today.1- Adding client identity protection to TLS (2000): available at
http://www.imc.org/ietf-tls/mail-archive/msg02004.html: It
consists of sending the ChangeCipherSpec message before the
Certificate and the CertificateVerify messages and after the
ClientKeyExchange message. The ChangeCipherSpec message is
sent to notify the receiving party that subsequent messages
will be protected under the cipher suite and keys negotiated
during the TLS Handshake. The keys are computed by applying
the PRF on the premaster secret and on the random values
generated by both the client and the server, as described in
TLS and SSL documents.2- Beller-Yacobi protocol (1997): described in "Handbook of
applied cryptography", CRC PRESS SERIES ON DISCRETE
MATHEMATICES AND ITS APPLICATIONS, BOXA RATON, FL, CRC PRESS,
US, 1997, pages 37- 39, 428, XP002204463, ISBN 0-8493-8523-7.3- Aura T, Ellison C, "Privacy and Accountability in Certificate
Systems", Research reports 61, [online], April 2000,
htpp://www.citeseer.ist.psu.edu/cs. This document describes an
authentication mechanism in which the client certificate is
sent encrypted.4- Samfat D, et. al., "Untraceability in Mobile Network", Mobicom
proceeding, 1995, pages 26-36.5- US Patent 6189098 - Client/server protocol for proving
authenticity (2001), Figures 3a, 3b. This patent also
describes a way to symmetrically encrypt the certificate by
its owner before sending it over the wire.6- http://www.niksula.cs.hut.fi/~sjsavola/SoN/essay.html (1999),
Identity Protection Exchange: The Identity Protection Exchange
is designed to separate the Key Exchange information from the
identity and authentication related information. A common
share secret can be established before identification and
authentication related information is exchanged and encryption
provides protection of the communicating identities.7- Just Fast Keying (JFKi, 2003),
http://people.csail.mit.edu/canetti/materials/jfk.pdf,
computes a secret key from DH exchange and encrypts the
certificate with this key.8- The SIGMA protocol (2001), idem for JFK.
9- http://pastel.paristech.org/1168/01/these_ibrahim_02-04-05.pdf
(French document, 2004), see Chapter 6.B. Does this disclosure relate to an unpublished pending patent application?: NO C. Does this disclosure apply to all IPR owned by the submitter?: YES
IV. Licensing Declaration The Patent Holder states that its position with respect to licensing any patent claims contained in the patent(s) or patent application(s) disclosed above that would necessarily be infringed by implementation of the technology required by the relevant IETF specification ("Necessary Patent Claims"), for the purpose of implementing such specification, is as follows(select one licensing declaration option only): No License Required for Implementers. Licensing information, comments, notes, or URL for further information: No information submitted Note: The individual submitting this template represents and warrants that he or she is authorized by the Patent Holder to agree to the above-selected licensing declaration.
V. Contact Information of Submitter of this Form (if different from the Contact Information above) Name: Mohamad Badra Title: Department: Address1: Address2: Telephone: 00334-73-40-73-58 Fax: Email: badra@isima.fr
VI. Other Notes: No information submitted