Mobile credentials

[Magnus Nystrom <[e-mail]>]

All,

Please find attached to this email a memo discussing the use of and
potential need for a PDU format and associated protocol for down- (and
potentiall up-) load of personal credentials, such as private keys and
X.509 certificates.

Stephen Farrell of Baltimore is likely to give a presentation on this
subject at the upcoming IETF meeting in Adelaide. We are currently
unsure of whether this would be a work item for PKIX or for some BOF
(or at all), but at least it seems as if this mailing list would be a
good starting point. Comments are of course welcome and solicited.

Thanks,
-- Magnus & Stephen

Magnus Nyström,  RSA Laboratories
Stephen Farrell, Baltimore Technologies
---------------------------------------------------
                           Mobile credentials

1 Introduction

As the number, and more particularly the number of different types,
of devices, (particularly wirless), connecting to the Internet 
increases, the issue of credential mobility becomes an issue for 
IETF standardization. This note presents some background and 
existing work on the topic and recommends pursuing this topic in 
either the PKIX WG or a BOF.

2 Mobile Credentials

2.1 Background

A nice feature of smart-card based PKIs, in addition to the security
offered by the cards themselves, is the "free-seating solution," or
the portability of user's credentials. In order to provide a similar
solution to environments based on purely software implementations or 
"virtual cards" (a.k.a "soft tokens," software files containing 
information normally stored on smart cards) some kind of credential 
store from which users can download their soft-tokens, using some 
specified protocol is required. This protocol will provide mobility
for credentials.

Such a solution would also allow users to have identical credentials
on, e.g. their mobile phone as in their desktop. Adding an upload
protocol to the solution means that it in principle is possible to
always have the credential store up-to-date.

If a specification for a smart card application also specifies how to
store the application's data in a single software file, then it will
be possible to use this file format as a "virtual card" or "soft
token". Soft tokens can be used, e.g., for transfer of information
for later storage on a real card, or for use within a token-aware
system not using "real" tokens such as smart cards. An advantage of
having the soft token format similar to the "real" token format is
that the "format" layer in the software does not have to know if it
is dealing with a real token or not. Further, if the soft token
format is well known, it will in principle be possible to download
such a token from a "credential server". By doing this one would in
principle accommodate what generally is known as the "free seating
solution" - users will be able to use a single set of credentials
regardless of where they happen to work.

Even in some cases where real smart cards are used, there may
be some benefit to using such a protocol - e.g. when a new card
is received, but "old" credentials should be used. If the cards
offered the appropriate install and delete interfaces, then the
credentials could be (securely) moved between cards.

Many desktop applications also require mobility of credentials, for 
example to  support some "kiosk" style operation, when a user 
upgrades a PC, or when "hot-desking". It is sometimes required to 
integrate such credential mobility with single-sign-on solutions. A 
protocol that could be used in the smart card case, can also be 
used to solve this case.

Finally, some applications may benefit from being able to migrate
credentials from a desktop to a smart card, in particular where
the smart card using device has limited user interface capabililies,
e.g. a mobile phone.

2.2 Security Issues

Mobile credentials will never be as secure as a "pure" smart card 
solution. However, reasonable security may be accomplished through 
some simple means, outlined in the following sections. One should 
keep in mind, however, that platforms to which credentials are 
downloaded usually cannot be regarded as tamper-resistant, and it 
therefore is not too hard to analyze contents of their memories. 
Further, storage of private keys, even if they are encrypted, on 
a credential server, will be unacceptable in some environments.

2.2.1 Confidentiality Protection

Private information in credentials must be protected by
encryption. The key for this encryption can be derived from a
password, but can also be something stronger. As an example of a
stronger method, one could consider the user authenticating to the
credential store using some strong authentication method (not
requiring public-key cryptography) and then downloading (over a
confidentiality-protected connection) not only the credentials but
also (parts of) the key to unlock the card. This way, the key used to
protect the credentials will not be derived from the user's password
solely. Further, in order to make it harder for a credential store
administrator to find out about users' private objects, the key
stored at the operator's server may be combined with a user-derived
key to form an actual key-encryption key.

2.2.2 Integrity Protection

Credentials must be integrity protected, since it would otherwise be
possible for an attacker to substitute parts of the credentials
(e.g. trusted certificates) with something more advantageous for
the attacker. Once again, the key for this integrity-protection may
be derived from a user password, but in this case, it could also be
the user's own private key (assuming that private objects on the
token are decrypted before the integrity check is done).

2.2.3 Down- and Up-load protocols

The copy of the credentials stored in the credential store should
always be up-to-date, in order to provide for a true free-seating
solution. This means that uploads should be performed as soon as
changes are made to the user's copy of the credentials. A user could
always downloads the credentials from the store when e.g. connecting
to the network. If the store is unavailable, e.g. due to a roaming
user, a locally cached copy of the credentials may be used. The 
protocols used must be integrity protected, and a user might be 
required to do a strong (public-key based) authentication in order 
to upload credentials.

2.3 Other Issues

In addition to the specific issues raised above, the following
more generic issues may pose challenges in providing a solution
to this problem:

- IPR: Some of the useful mechanisms are encumbered
- Privacy: Use of a credential store should not decrase the
  expectations of the user for privacy (e.g. if the credentials
  are subsequently used for authentication with some protocol
  that does provide privacy)
- Robustness: Credential stores should not unacceptably 
  increase the potential for denial-of-service attacks
- Performance: Clients for the putative protocol should not
  typically have to wait too long for access to credentials
- Bootstrapping: The use of, e.g. TLS server authentication,
  depends on the client having a (set of) trusted root(s) - as
  the putative protocol may be providing these roots, there 
  may be some hard bootstrapping issues.
  
Finally, we note that whether or not the user authentication,
credential protection and specific credential formats should 
be separated, or should be intertwined, is an open issue.

3 Prior work

3.1 The "inetOrgPerson" object class

In [6], an auxiliary object class, "inetOrgPerson," is specified. One
attribute defined for use with this object class is "userPKCS12",
which is a PKCS #12 [4] PDU, containing personal credentials.

3.2 The "pkcsEntity" object class

In [3], another auxiliary object class, "pkcsEntity," is
specified. This object class is capable of carrying "userPKCS12" PDUs
as well as "pKCS15Token" PDUs.

3.3 Active Directory's "user" object class

In [2], an object class "user" is specified, holding, among other
attributes a "privateKey" attribute, whose values are encrypted
private keys.

4 Possible Specifications needed

4.1 Soft-token up- or down-load protocol

This protocol could be made very simple; it could in principle be
specified in terms of the current http [1] protocol, using the
request-response model specified therein. Credential servers would
listen on certain ports for connection requests, perform TLS
handshakes and act in accordance with received requests. Some
stronger authentication methods may have to be defined for use with
http.

4.2 Specification of soft token format

The specification should leverage some existing specification. As an
example, the current draft of PKCS #15 [5] includes a format for 
credentials, which could simplify this task, but other solutions are
clearly also possible.

5 Discussion and Conclusion

Evidently, all the examples from section 3 are based on the use of 
LDAP-accessible directories as "credential stores." A disadvantage 
with this is that LDAP, despite its name, can be considered 
"heavy-weight" in this context, since a very simple protocol for 
up- and down-loads would suffice. LDAP is clearly to complex for 
wireless devices such as current mobile phones. The solution in 
Section 3.3 above also suffers from the use of non-standard 
attributes.

The conclusion is therefore, that while the work mentioned in
sections 3.1 - 3.3 is useful and provides a basic framework, it does
not quite fullfil our needs of a simple protocol and a standardized
format for personal credentials.

In summary, this topic appears to be suited for consideration 
in the PKIX WG, or, perhaps more likely, for a more BOF on the 
topic; followed by standardization of a credential mobility 
protocol and (set of) credential format(s).

5 References

[1] "R. Fielding, J. Gettys, J. Mogul,, H. Frysyk, L. Masinter,
    P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol --
    HTTP/1.1", IETF RFC 2616, June 1999.

[2] "Microsoft Windows NT Active Directory Technical Summary,"
    Microsoft Corp., September 1997.

[3] "PKCS #9 v2.0: Selected object classes and attribute types," RSA
    Laboratories, February 2000.

[4] "PKCS #12 v1.0: Personal Information Exchange Syntax," RSA
    Laboratories, June 1999.

[5] "PKCS #15 v1.1 (Draft): Cryptographic Token Information Syntax
    Standard," RSA Laboratories, December 1999.

[6] M. Smith, "Definition of the inetOrgPerson LDAP Object Class,"
    IETF work in progress, January 2000