datatracker.ietf.org
Sign in
Version 5.10.0, 2014-12-21
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 relevant entry form 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
Email:contact@enst.fr
Other Info:
(address,phone,etc)

T: 0033145817777

III. Contact Information for the IETF Participant Whose Personal Belief Triggered this Disclosure:
Name:Mohamad Badra
Email:badra@isima.fr
Other Info:
(address,phone,etc)

T: 00334-73-40-73-58

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)
Revisions: 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: 03.04.2007
Country: France

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
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
Name:Mohamad Badra
Email:badra@isima.fr