IPR Details
GROUPE DES ECOLES DES TELECOMMUNICATIONS - ECOLE NATIONALE SUPERIEURE DES TELECOMMUNICATIONS 's General License Statement

Submitted: December 17, 2008 under the rules in RFC 3979 as updated by RFC 4879

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.

I. Patent Holder/Applicant ("Patent Holder")

Holder legal name
GROUPE DES ECOLES DES TELECOMMUNICATIONS - ECOLE NATIONALE SUPERIEURE DES TELECOMMUNICATIONS

II. Patent Holder's Contact for License Application

Holder contact name
GROUPE DES ECOLES DES TELECOMMUNICATIONS - ECOLE NATIONALE SUPERIEURE DES TELECOMMUNICATIONS
Holder contact email
contact@enst.fr
Holder contact info

T: 0033145817777
F: 0033145897906

III. Disclosure of Patent Information i.e., patents or patent applications required to be disclosed by RFC 3979 as updated by RFC 4879

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?:

Has patent pending
Yes

IV. Statement

Statement


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:

V. Contact Information of Submitter of this Form

Submitter name
Mohamad Badra
Submitter email
badra@isima.fr

Only those sections of the relevant entry form where the submitter provided information are displayed.