[ietf-enroll] Major comment about the ietf-enroll initiative

[Thierry Moreau]

Subject: Major comment about the ietf-enroll initiative

To the ietf_enroll mailing list:

It is very interesting that, at last, an IETF-related initiative
addresses the
issue of *initial* establishment of cryptographic keys (with an
authentication
perspective) as a separate issue from the *session key* establishment
(with
the goal of seamless and ubiquitous security).

In 1996-1997, I was exposed to the practical problem of enrollment in a
financial application, and then I was able to afford the time to think
about
the problem thoroughly, and I came up with SAKEM, Secret Authentication
Key
Establishment Method (more on that later).

Going through the mailing list archive and the internet draft
(draft-pritikin-ttimodel-00.txt), I attempt to summarize the work
achieved by
the discussion and member contribution:

  1) The problem statement is fairly accurate.

  2) The participants in the discussion noticed the general lack of
interest
     for this topic by the IT security people. Let me suggest the
following
     rationale:
       a) cryptography can only *shift* or *leverage* the security
issues
          from application data management to key management, but it can
not
          *solve* the issues, a fact that IT security people prefer to
          ignore (or recursively shift farther until management
attention is
          lost, or auditors are fed up, e.g. PKI),
       b) it is paradoxical that the authentication formalities
surrounding
          the enrolment procedures is the cornerstone of system-wide
trust,
          while the economic factors and operational contingencies
usually
          spoil the protection potential of these formalities,
       c) because the enrollment procedure inescapably embeds
formalities,
          it is conveniently stated "outside the scope" of may security
          specifications,
       d) the fact that authentication formalities are necessarily
imperfect
          is used as an excuse for not securing a bound between the
          formalities and the authentication key (SAKEM addresses this
          point).

3)   The unbalanced nature of the enrolment process has been recognized
(a
     petitioner-client and a registrar-server is the most frequent
scenario).

4)   Transport independence of the TTI model appears important as the
     technological environment is very diversified.

Now let me comment on the TTI model. You may guess that these comments
are
influenced by the SAKEM design, which shaped my understanding of
enrollment
issues. Beyond that, the TTI ietf-enroll initiative and the TTI model
appear
to be a fundamental move in the right direction (addressing the
enrollment
issues instead of avoiding them!).

(A)  The petitioner [should] be allowed to interact directly with the
     registrar: since they are deemed to do so after the enrollment, the

     transport link should be available in most application instances,
which
     is not the case between the petitioner and the introducer.

(B)  The value added by the introducer is authentication confidence for
the
     registrar benefit. I omit the petitioner confidence that he is
dealing
     with the proper registrar, admittedly this is a narrow view of the
TTI
     model, but perhaps the foremost scenario.

(C)  Presumably, the authentication confidence offered by the introducer
is
     critically dependent on the proper accomplishment of some
authentication
     formalities. If those formalities are solely based on a prior AA
     relationship between the petitioner and introducer, the TTI model
     becomes a (more or less) automated mechanism to re-use a
pre-existing
     cryptographic association.

     It is not clear from the TTI model draft whether the model is such
a
     transitivity processing model or a genuine enrollment model:

     On page 5 (3rd paragraph), the TTI model draft document states "The

     Introducer must authenticate to the Petitioner and Registrar using
the
     authentication and authorization mechanisms currently in place.
This
     recursive use of prior associations is the strength of TTI."

     Nonetheless, on page 12 (3rd paragraph), the TTI model documents
     stresses the authentication provided by the introducer: "This
document
     develops the concept of the Introducer, a new construct in the
normally
     bi-entity discussions of secure enrollment. This serves as an
     alternative to the historically loosely defined 'out-of-band'
security
     measures. The security implications of a transitive relationship
still
     apply. A compromised introducer could act to enable enrollment of
     unexpected elements into a secure domain in much the same way that
a
     compromised 'out-of-band' mechanism can be used to subvert a
classic
     enrollment scenario."  After all, isn't the Introducer stating
"Bob,
     this is Alice."

Overall, the TTI model document correctly states the enrollment problem
but
provides an AA transitivity processing model, instead of a genuine
enrollment
model.

In SAKEM, the petitioner first establishes a shared secret key with the
registrar, using public key cryptography. A registration reference
number is
piggybacked to this exchange. The introducer performs the authentication

formalities on behalf of the registrar. The registration reference
number
secures the bound between the authentication formalities and the secret
key.

The SAKEM proposal is discussed at length at
http://www.connotech.com/SAKEM.HTM. It is covered by patents (e.g. US
patent
6,061,791).
The TTI "petitioner" is the SAKEM "applicant".
The TTI "registrar" is the SAKEM "issuer".
The TTI "introducer" is the SAKEM "issuer agent".
The above "registration reference number" is the SAKEM "pass reply".

I hope the above information will assist you in further advancing the
field of
strong entity authentication in support of Internet security.

Sincerely,

--

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

e-mail: thierry.moreau at connotech.com