[ietf-enroll] Some thoughts on ENROLL's direction

[Thierry Moreau]

Dear IETF-ENROLL participants:

I just read the discussion list messages from the last few
months, and a significant step forward has been made.

As I understand it, the main achievement is the recognition
that enrollment requires 1) a minimalist OOB (Out-Of-Band)
channel that is somehow "more trusty" than the in-band
channel and 2) some human decision-making, or more precisely
authentication-assurance assessment (perhaps reflected in a
very unsuspicious enrollment policy, but always explicit in
the enrollment model).

In the 1990's, I closely studied the field deployment of
electronic payment devices that use secret cryptographic keys
for authentication and encryption. There is an analogy to be
made between the requirement to have the electronic payment
device initialized under tightly controlled procedures and
terminals, and the OOB channel in the enrollment model.

1) A comment

Roddy, Sue saroddy at tycho.ncsc.mil wrote (Mon Apr 19
13:37:39 EDT 2004):
 >[With the proposed ietf-enroll model], if a device comes off
 >a production line with some established information, it can
 >convey that information into some management entity at first
 >use time, which would authenticate it and allow subsequent
 >replacement of key, upgrade of configuration, etc.  The
 >Out-of-Band channel would be that the provisioning or sale
 >of that serial number is now in a given domain.

Agreed, provided there is trust between the management entity
end the device manufacturer. The equivalent strategy was
contemplated for electronic payment devices, but I am not
aware of any actual use.

2) Positioning of the SAKEM procedure and technology

As it stands, the model calls for a one-way OOB channel with
digital data transmission capability, and some
authentication-assurance assessment by a *single* party (am I
reading the model correctly on this point?).

It might be attractive to some participants to augment the
model with an alternative where the OOB channel is a
conversation between two humans (thus dropping the digital
data transmission capability requirement) and the
authentication assessment is done by one of them (or both of
them when the management entity authentication is critical).
If such is the case, the SAKEM procedure should be of
interest (In was mentioned on the ietf-enroll list in a
previous message
http://mailman.mit.edu/pipermail/ietf-enroll/2003/000096.html
). 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).

3) A different perspective on enrollment issues for
e-government

Some participants might be interested in another perspective
on the enrollment issues: the US Government e-authentication
initiative (see the document NIST SP-800-63
http://csrc.nist.gov/publications/drafts/draft-sp800-63.pdf).
A new version of NIST SP-800-63 should be issued by NIST
within a few weeks. This initiative is limited to
authentication of remote entities, individuals and legal
entities (but not network devices) for the purpose of
e-government, but without attention paid to the "intent to
agree" property of digital signatures. It defines four levels
of authentication strength. Basically, the ietf-enroll
initiative comes from the openness of radio networks, and the
NIST initiative comes from the urgent need for consistent and
reliable authentication mechanisms over open networks for
electronic delivery of government services.

Perhaps by paying attention to the terminology used in the
document NIST SP-800-63, the ietf-enroll model would
facilitate the development of enrollment protocols that are
compliant to NIST authentication level 2 (password-based
authentication) or level 3 (cryptography-assisted
authentication, but without a hardware token).

Sincerely,

-- 

- Thierry Moreau

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

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

web site: http://www.connotech.com
e-mail: thierry.moreau at connotech.com