INTERNET-DRAFT A. Arsenault
expires in six months Diversinet
S. Farrell
Baltimore Technologies
November 2000
Securely Available Credentials - Requirements
<draft-ietf-sacred-reqs-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes requirements to be placed on Securely
Available Credentials (SACRED) protocols.
This is the initial draft of the SACRED requirements specification
and is therefore highly likely to change substantially.
Discussion of this draft is taking place on the SACREDmailing list
of the IETF SACRED working group (see http://www.imc.org/ietf-sacred
for subscription information).
Table Of Contents
Status of this Memo.............................................1
Abstract........................................................1
Table Of Contents...............................................1
1. Introduction.................................................2
1.1 Background and Motivation..............................3
1.2 Working Group Organization and Documents...............4
1.3 Structure of This Document.............................4
Arsenault & Farrell [Page 1]
INTERNET-DRAFT November 2000
2. Framework Requirements.......................................5
2.1 Credential Server and Direct solutions.................5
2.2 User authentication....................................7
2.3 Credential Formats.....................................7
2.4 Transport Issues.......................................7
3. Protocol Requirements........................................7
3.1 Vulnerabilities........................................8
3.2 General Protocol Requirements..........................8
3.3 Requirements for Credential Server-based solutions.....9
3.4 Requirements for Direct-Transfer Solutions............10
4. Open Issues.................................................10
5. Security Considerations.....................................11
References.....................................................12
Authors' Addresses.............................................12
Full Copyright Statement.......................................12
Appendix A: A note on SACRED vs. hardware support..............13
1. Introduction.
"Credentials" are information that can be used to establish the
identity of an entity, or help that entity communicate securely.
Credentials include such things as private keys, trusted roots,
tickets, or the private part of a Personal Security Environment
(PSE)[RFC2459] - that is, information used in secure communication
on the Internet. Credentials are used to support various Internet
protocols, e.g. S/MIME, IPSec and TLS.
In simple models, users and other entities (e.g. computers like
routers) are provided with credentials, and these credentials stay
in one place. However, the number, and more importantly the number
of different types, of devices that can be used to access the
Internet is increasing. It is now possible to access Internet
services and accounts using desktop computers, laptop computers,
wireless phones, pagers, personal digital assistants (PDAs) and
other types of devices. Further, many users want to access private
information and secure services from a number of different devices,
and want access to the same information from any device. Similarly
credentials may have to be moved between routers when they are
upgraded.
This draft identifies a set of requirements for credential mobility.
The Working Group will also produce companion documents, which
describe a framework for secure credential mobility, and a set of
protocols for accomplishing this goal.
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC2119].
<<Editorial comments are in angle brackets, like this>>.
Arsenault & Farrell [Page 2]
INTERNET-DRAFT November 2000
1.1 Background and Motivation
In simple models of Internet use, users and other entities are
provided with credentials, and these credentials stay in one place.
For example, Mimi generates a public and private key on her desktop
computer, provides the public key to a Certification Authority (CA)
to be included in a certificate, and keeps the private key on her
computer. It never has to be moved.
However, the number, and more importantly the number of different
types, of devices that can be used to access the Internet is
increasing. It is now possible to access Internet services and
accounts using desktop computers, laptop computers, wireless phones,
pagers, personal digital assistants (PDAs) and other types of
devices. Further, many users want to access private information and
secure services from a number of different devices, and want access
to the same information from any device.
For example, Mimi may want to able to send signed e-mail messages
from her desktop computer when she is in the office, and from her
laptop computer when she is on the road, and she does not want
message recipients to know the difference. In order to do this, she
must somehow make her private key available on both devices - that
is, that credential must be moved.
Similarly, Will may want to retrieve and read encrypted e-mail from
either his wireless phone or from his two-way pager. He wants to
use whichever device he has with him at the moment, and does not
want to be denied access to his mail or to be unable to decrypt
important messages simply because he has the wrong device. Thus, he
must be able to have the same private key available on both devices.
The following scenario relating to routers has also been offered:
"Once upon a time, a router generated a keypair. The administrators
transferred the public key of that router to a lot of other (peer)
routers and used that router to encrypt traffic to the other
routers. And this was good for many years. Then one day, the network
administrators found that this particular little router couldnÆt
handle an OC-192. So they trashed it and replaced it with a really
big router. While they were there, the craft workers inserted a
smart card into the router and logged into the router. They give
the appropriate commands and entered the correct answers and so the
credentials (keypair) were transferred to the new, big router.
Alternatively, the craft people could have logged into the router,
given it a minimal configuration and transferred the credentials
from a credential server to the router. They had to perform the
correct incantations and authentications for the transfer to be
successful. In this way, the identity of the router was moved from
an old router to a new one. The administrators were glad that they
didnÆt have to edit the configurations of all of the peer routers as
well."
Arsenault & Farrell [Page 3]
INTERNET-DRAFT November 2000
It is generally accepted that the private key in these examples must
be transferred securely. In the first example, the private key
should not be exposed to anyone other than Mimi herself (and
ideally, it would not be directly exposed to her). Furthermore, it
must be transferred correctly. It must be transferred to the proper
device, and it must not be corrupted - improperly modified - during
transfer.
Making credentials securely available (in an interoperable fashion)
will provide substantial value to network owners, administrators,
and end users. The intent is that this value be provided largely
independent of the hardware device used to access the secure
credential and the type of storage medium to which the secure
credential is written. Different credential storage devices, (e.g.
desktop or laptop PC computer memory, a 3.5 inch flexible diskette,
a hard disk file, a cell phone, a smart card, etc.) will have very
different security characteristics and, often very different
protocol handling capabilities. Using SACRED protocols, users will
be able to securely move their credentials between different
locations, different Internet devices, and different storage media
as needed.
In the remainder of this draft we present a set of requirements for
the secure transfer of software-based credentials.
1.2 Working Group Organization and Documents
<<This section can be filled in more completely as work progresses
and we know more about what the rest of the documents are.>>
The Securely Available Credentials (SACRED) Working Group is working
on the standardization of a set of protocols for securly transfering
credentials among devices. A general framework is being developed
that will give an abstract definition of protocols which can meet
the credential-transfer requirements. This framework will allow for
the development of a set of protocols, which may vary from one
another in some respects. Specific protocols which conform to the
framework can then be developed.
Work is being done on a number of documents. This document
identifies the requirements for the general framework, as well as
the requirements for specific protocols. Another document will
describe the protocol framework. Still others will define the
protocols themselves.
1.3 Structure of This Document
Section 1 of this document provides an introduction to the problem
being solved by this working group. Section 2 describes requirements
on the framework. Section 3 identifies the overall requirements for
secure credential-transfer protocols, and separate requirements for
the two different classes of solutions. Section 4 addresses
remaining issues. Section 5 identifies Security Considerations.
Arsenault & Farrell [Page 4]
INTERNET-DRAFT November 2000
Appendix A describes the relationship of the SACRED solutions and
credential-mobility solutions involving hardware components such as
smart cards.
2. Framework Requirements
This section describes requirements that the SACRED framework has to
meet, as opposed to requirements that are to be met by a specific
protocol that uses the framework.
2.1 Credential Server and Direct solutions
There are at least two different ways to solve the problem of secure
credential transfer between devices. One class of solutions uses a
"credential server" as an intermediate node, and the other class
provides direct transfer between devices.
A "credential server" can be likened to a server that sits in front
of a repository where credentials can be securely stored for later
retrieval. The credential server is active in the protocol, that is,
it implements security enforcing functionality.
To transfer credentials securely from one end device to another is a
straightforward two-step process. Users can have their credentials
securely "uploaded" from one device, e.g., a wireless phone, to the
credential server. They can be stored on the credential server, and
"downloaded" when needed using another device; e.g., a two-way
pager.
Some advantages of a credential server approach compared to
credential transfer are:
1. It provides a conceptually clean and straightforward approach.
For all end devices, there is one protocol, with a set of
actions defined to transfer credentials from the device to the
server, and another set of actions defined to transfer
credentials from the server to the device. Furthermore, this
protocol involves clients (the devices) and a server (the
credential server), like many other Internet protocols; thus,
the design of this protocol is likely to be familiar to most
people familiar with most other Internet protocols.
2. It provides for a place where credentials can be securely stored
for arbitrary lengths of time. Given a reasonable-quality server
operating under generally accepted practices, it is unlikely the
credentials will be permanently lost due to a hardware failure.
This contrasts with systems where credentials are only stored on
end devices, in which a failure of or the loss of the device
could mean that the credentials are lost forever.
3. The credential server may be able to enforce a uniform security
policy regarding credential handling. This is particularly the
case where credentials are issued by an organization for its own
purposes, and are not "created" by the end user, and so must be
governed by the policies of the issuer, not the user.
Arsenault & Farrell [Page 5]
INTERNET-DRAFT November 2000
However, the credential server approach has some potential
disadvantages, too:
1. It might be somewhat expensive to maintain and run the
credential server, particularly if there are stringent
requirements on availability and reliability of the server.
2. The credential server may have to be "trusted" in some sense and
also introduces a point of potential vulnerability. (See the
Security Considerations section for some of the issues.) Good
protocol and system design will limit the vulnerability that
exists at the credential server, but at a minimum, someone with
access to the credential server will be able to delete
credentials and thus deny the SACRED service to system users.
Thus, some users may prefer a different class of solution, in which
credentials are transferred directly from one device to another
(i.e. having no intermediary element that processes or has any
understanding of the credentials).
For example, consider the case where Mimi sends a message from her
wireless phone containing the credentials in question, and retrieves
it using her two-way pager. In getting from one place to another,
the bits of the message cross the wireless phone network to a base
station. These bits are likely transferred over the wired phone
network to a message server run by the wireless phone operator, and
are transferred from there over the Internet to a message server run
by the paging operator. From the paging operator they are
transferred to a base station and then finally to MimiÆs pager.
Certainly, there are devices other than the original wireless phone
and ultimate pager that are involved in the credential transfer, in
the sense that they transmit bits from one place to another.
However, to all devices except the pager and the wireless phone,
what is being transferred is an un-interpreted and unprocessed set
of bits. No security-related decisions are made, and no actions are
taken based on the fact that this message contains credentials, at
any of the intermediate nodes. They exist simply to forward bits.
Thus, we consider this to be a "direct" transfer of credentials.
Solutions involving the direct transfer of credentials from one
device to another are potentially somewhat more complex than the
credential-server approach, owing to the large number of different
devices and formats that may have to be supported. Complexity is
also added due to the fact that each device may in turn have to
exhibit the behavior of both a client and a server.
We believe that both classes of solutions are useful in certain
environments, and thus that the SACRED framework will have to define
solutions for both. The extent to which elements of the above
solutions overlap remains to be determined.
This all leads to our first set of requirements:
Arsenault & Farrell [Page 6]
INTERNET-DRAFT November 2000
F1. The framework MUST support both "credential server" and
"direct" solutions.
F2. The "credential server" and "direct" solutions SHOULD use
the same technology as far as possible.
2.2 User authentication
There is a wide range of deployment options for credential mobility
solutions. In many of these cases, it is useful to be able to re-use
an existing user authentication scheme, for example where passwords
have previously been established, it may be more secure to re-use
these than try to manage a whole new set of passwords. Different
devices may also limit the types of user authentication scheme that
are possible, e.g. not all mobile devices are practically capable of
carrying out asymmetric cryptography.
F3. The framework MUST allow for protocols which support
different user authentication schemes
2.3 Credential Formats
Today there is no single standard format for credentials and this is
not likely to change in the near future. There are a number of
fairly widely deployed formats, e.g. [PGP], [PKCS#12] that have to
be supported. This means that the framework has to allow for
protocols supporting any credential format.
F4. The details of the actual credential type or format MUST be
opaque, that is, the protocol MUST NOT depend on the
internal structure of any credential type or format
<<Open issue: Should we place any structure on credentials or really
just regard them as octet strings? The latter is simpler, except
that perhaps a password is used both to authenticate to a credential
server *and* to encrypt the private parts of a pkcs#12 file.>>
2.4 Transport Issues
Different devices allow for different transport layer possibilities,
e.g. current WAP 1.x devices do not support TCP. For this reason the
framework has to be transport "agnostic".
F5. The framework MUST allow use of different transports.
3. Protocol Requirements
In this section, we identify the requirements for secure credential-
transfer solutions. We will begin by listing a set of relevant
vulnerabilities and therequirements that must be met by all
solutions. Then we identify additional requirements that must be met
by solutions involving a credential server, followed by additional
Arsenault & Farrell [Page 7]
INTERNET-DRAFT November 2000
requirements that must be met by solutions involving direct transfer
of credentials.
3.1 Vulnerabilities
<<Is this a reasonable way to proceed? That is, listing
vulnerabilities and requiring that protocols explicitly specify the
protection that they provide against each threat? Even if so, this
section undoubtedly needs more work.>>
This section lists the vulnerabilities against which a SACRED
protocol SHOULD offer protection. Any protocol claiming to meet the
requirements listed in this document MUST explicitly indicate how
(or whether) it offers protection for each of these vulnerabilities.
V1. A passive attacker can watch all packets on the network and
later carry out a dictionary attack.
V2. An attacker can attempt to masquerade as a credential server
in an attempt to get a client to reveal information on line
that allows for a later dictionary attack.
V3. An attacker can attempt to masquerade as a credential server
in an attempt to get a client to reveal information via use
of apparently correct credentials that allows for a
dictionary attack. <<Might not ever be possible?>>
V4. An attacker could overwrite a repository entry so that when
a user subsequently uses what they think is a good
credential, they expose information about their password
(and hence the "real" credential).
V5. An attacker can copy a credential server's repository and
carry out a dictionary attack.
V6. An attacker can attempt to masquerade as a client in an
attempt to get a server to reveal information that allows
for a later dictionary attack.
V7. An attacker can persuade a server that a successful login
has occurred, even if it hasn't. <<Don't know if SACRED
requires that the server knows whether or not a login
succeeded>>
V8. (Upload) An attacker can overwrite someone else's
credentials on the server.
V9. (When using password-based authentication) An attacker can
force a password change to a known (or "weak") password.
V10. An attacker can attempt a man-in-the-middle attack for lots
of reasons...
V11. User enters password instead of name.
V12. An attacker could attempt various denial-of-service attacks.
3.2 General Protocol Requirements
Looking again at the examples described in Section 1.1, we can
readily see that there are a number of requirements that must apply
to the transfer of credentials if the ultimate goal of supporting
the Internet security protocols (e.g., TLS, IPSec, S/MIME) is to be
Arsenault & Farrell [Page 8]
INTERNET-DRAFT November 2000
met. For example, the credentials must remain confidential at all
times; it is unacceptable for nodes other than the end-userÆs
device(s) to see the credentials in any readable, cleartext form.
These, then, are the requirements that apply to all secure
credential-transfer solutions:
G1. Credential transfer both to and from a device MUST be
supported.
G2. Credentials MUST never be present in cleartext at any device
other than the end user's.
G3. All transferred credentials SHOULD be authenticated in some
way (e.g., digitally signed or MAC-ed).
G4. All transferred credentials MUST be integrity protected in
some way (e.g., digitally signed or MAC-ed).
G5. The protocol MUST support a range of cryptographic
algorithms, including symmetric and asymmetric algorithms,
hash algorithms, and MAC algorithms.
G6. The protocol MUST support the use of various credential
types and formats (e.g., X.509, PGP, PKCS12, ...).
G7. One mandatory to support credential format MUST be defined.
G8. One mandatory to support user authentication scheme MUST be
defined.
G9. Credentials MAY be labelled with a text handle to allow the
end user to select amongst a set of credentials or to name a
particular credential.
G10. Full I18N support is REQUIRED (via UTF8 support).
G11. The protocol MUST be able to support privacy, that is,
anonymity for the client.
G12. Transferred credentials MAY incorporate timing information,
for example a "time to live" value determining the maximum
time for which the credential is to be usable following
transfer/download.
3.3 Requirements for Credential Server-based solutions
The following requirements assume that there is a credential server
from which credentials are downloaded to the end user device, and to
which credentials are uploaded from an end user device.
S1. Credential downloads (to an end user) and upload (to the
credential server) MUST be supported.
S2. Credentials MUST only be downloadable following user
authentication.
S3. It MUST be possible to ensure the authenticity of a
credential during upload.
S4. Different end user devices MAY be used to
download/upload/manage the same set of credentials.
S5. The credential server MUST NOT have easy access to the
cleartext credentials.
S6. Credential servers MUST be authenticated to the user for all
operations except (possibly) download.
Arsenault & Farrell [Page 9]
INTERNET-DRAFT November 2000
S7. It MUST be possible to authenticate the credential server to
the user prior to download (if the user is able to verify
the authentication).
S8. The user SHOULD only have to enter a single secret value in
order to download and use a credential.
S9. Sharing of secrets across multiple servers MUST be possible,
so that penetration of some servers does not expose the
private parts of a credential ("m-from-n" operation).
S10. The protocol MUST support "away-from-home" operation, where
the user enters both a name and a domain (e.g.
RoamingStephen@baltimore.ie) and the domain can be used in
order to locate the user's credential server.
S11. Users MUST be able to manage their credentials stored on the
credential server.
S12. The user MUST be able to retrieve a list of their
credentials stored on a server; add credentials to the
server; delete credentials from the server.
S13. Client-initiated authentication information (e.g. password)
change MUST be supported.
S14. The user SHOULD be able to retrieve a list of
accesses/changes to their credentials.
S15. The credential server protocol MUST support user self-
enrollment. One scenario calling for this is where a
previously unknown user uploads his credential without
requiring manual operator intervention.
S16. The credential server protocol MUST NOT prevent bulk
initializing of a credential server's repository.
3.4 Requirements for Direct-Transfer Solutions
The following requirements apply to solutions supporting the
"direct" transfer of credentials from one device to another. (See
Section 2 for the note on the meaning of "direct" in this case.)
D1. It SHOULD be possible for the receiving device to
authenticate that the credential package indeed came from
the purported sending device.
D2. In order for a sender to know that a credential has been
received by a recipient, it SHOULD be possible for the
receiving device to send an acknowledgment of credential
receipt back to the sending device, and for the sending
device to authenticate this acknowledgment.
4. Open Issues
This document is intended to foster discussion of the requirements
for secure credential transfer solutions. However, the authors
recognize that there are many issues that remain to be resolved.
Some of the most pressing are:
Vulnerabilities: Which attacks can/should the framework and protocol
protect against? What do we depend on the end user device for?
Arsenault & Farrell [Page 10]
INTERNET-DRAFT November 2000
Robustness: Credential stores should not unacceptably increase the
potential for denial-of-service or other attacks.
Performance: Users should not typically have to wait too long for
access to credentials.
Bootstrapping: The use of, e.g. TLS server authentication as a way
of having the client authenticate the credential server, depends on
the client having a (set of) trusted root(s). As the 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 that warrants
careful consideration.
5. Security Considerations
Mobile credentials will never be as secure as a "pure" hardware-
based solution, because of potential attacks through the operating
system of the end-user device. However, an acceptable level of
security may be accomplished through some simple means. In fact the
level of security may be improved (compared to password encrypted
files) through the use of sacred protocols.
The 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.
<<The wording here needs to be improved.>>
Although out of scope of the SACRED protocol development work,
implementations should carefully audit events that may be security
relevant. In particular credential server implementations should
audit all operations and should include information about the time
and source (e.g. IP address) of the operation, the claimed identity
of the client (possibly masked - see below), the type and result of
the operation and possibly other operation specific information.
Implementations should also take care not to include security
sensitive information in the audit trail, especially not sensitive
authentication information.
It may be sensible to mask the claimed identity in some way in order
to ensure that even if a user enters her password in a "username"
field, that that information is not in clear in the audit trail,
regardless of whether or not it was received in clear.
Similar mechanisms which should be supported, but which are out of
scope of protocol development include alerts and account locking, in
particular following repeated authentication failures.
Arsenault & Farrell [Page 11]
INTERNET-DRAFT November 2000
<<Probably should mention something about denial-of-service attacks
on credential servers. ItÆs not a huge deal, but we should at least
acknowledge it.>>
References
[PGP] Callas, J., Donnerhacke, L., Finney, H., & Thayer, R.,
"OpenPGP Message Format", RFC 2440.
[PKCS12] "PKCS #12 v1.0: Personal Information Exchange Syntax
Standard", RSA Laboratories, June 24, 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax
Standard," RSA Laboratories, June 2000.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119.
[RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet
Public Key Infrastructure - X.509 Certificate and CRL
profile", RFC 2459.
[RFC2616] "R. Fielding, J. Gettys, J. Mogul,, H. Frysyk, L.
Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer
Protocol - HTTP/1.1", RFC 2616.
Authors' Addresses
Alfred Arsenault
Diversinet Corp.
P.O. Box 6530
Ellicott City, MD 21042
USA
tel: +1 410-480-2052
email: aarsenault@dvnet.com
Stephen Farrell,
Baltimore Technologies,
61/62 Fitzwilliam Lane,
Dublin 2,
IRELAND
tel: +353-1-647-3000
email: stephen.farrell@baltimore.ie
Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. In addition,
the ASN.1 module presented in Appendix B may be used in whole or in
Arsenault & Farrell [Page 12]
INTERNET-DRAFT November 2000
part without inclusion of the copyright notice. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process shall be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix A: A note on SACRED vs. hardware support.
<<Moved this from section 1.1 where it looked a bit negative.
Probably important that this not be lost though.>>
One way of accomplishing many of the goals of the SACRED WG is to
put the credentials on hardware tokens - e.g., smart cards, PCMCIA
cards, or other devices. There are a number of types of hardware
tokens today that provide secure storage for sensitive information,
some degree of authentication, and interfaces to a number of types
of wireless and other devices. Thus, in the second example from
section 1.1, Will could simply put his private key on a smart card,
always take the smart card with him, and be assured that whichever
device he uses to retrieve his e-mail, he will have all of the
information necessary to decrypt and read messages.
However, hardware tokens are not appropriate for every environment.
They cost more than software-only solutions, and the additional
security they provide may or may not be worth the incremental cost.
Not all devices have interfaces for the same hardware tokens. And
hardware tokens are subject to different failure modes than typical
computers - it is not at all unusual for a smart card to be lost or
stolen; or for a PCMCIA card to physically break.
Thus, it is appropriate to develop complementary software-based
solution that allows credentials to be moved from one device to
another, and provides a level of security sufficient for its
environments. While we recognize that the level of security
provided by a software solution may not be as high as that provided
by the hardware solutions discussed above, and some organizations
may not consider it sufficient at all, we believe that a worthwhile
solution can be developed.
Finally, SACRED protocols can also complement hardware credential
solutions by providing standard mechanisms for the update of
Arsenault & Farrell [Page 13]
INTERNET-DRAFT November 2000
credentials which are stored on the hardware device. Today, this
often requires returning (with) the device to an administrative
centre, which is often inconvenient and may be costly. SACRED
protocols provide a way to update and manage credentials stored on
hardware devices without requiring such physical presence.
Arsenault & Farrell [Page 14]
