datatracker.ietf.org
Sign in
Version 5.6.2.p2, 2014-07-24
Report a bug

GROUPE DES ECOLES DES TELECOMMUNICATIONS - ECOLE NATIONALE SUPERIEURE DES TELECOMMUNICATIONS 's Statement about IPR related to draft-hajjeh-tls-identity-protection-08

Only those sections of the "Patent Disclosure and Licensing Declaration Template for Specific IPR Disclosures" where the submitter provided information are displayed.

Update this IPR disclosure. Note: Updates to IPR disclosures must only be made by authorized representatives of the original submitters. Updates will automatically be forwarded to the current Patent Holder's Contact and to the Submitter of the original 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:
Email: contact@enst.fr
III. Contact Information for the IETF Participant Whose Personal Belief Triggered this Disclosure:
Name: Mohamad Badra
Title:
Department:
Address1:
Address2:
Telephone: 00334-73-40-73-58
Fax:
Email: badra@isima.fr
IV. IETF Document or Other Contribution to Which this IPR Disclosure Relates:
Internet-Draft:"Credential Protection Ciphersuites for Transport Layer Security (TLS)"
(draft-hajjeh-tls-identity-protection-08)
V. 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. If an Internet-Draft or RFC includes multiple parts and it is not reasonably apparent which part of such Internet-Draft or RFC is alleged to be covered by the patent information disclosed in Section V(A) or V(B), it is helpful if the discloser identifies here the sections of the Internet-Draft or RFC that are alleged to be so covered:
No information submitted
VI. 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.
VII. Contact Information of Submitter of this Form (if different from the Contact Information above)
Name: Mohamad Badra
Title:
Department:
Address1:
Address2:
Telephone: 04-73-40-73-58
Fax:
Email: badra@isima.fr
VIII. Other Notes:
No information submitted