25-08-2017, 09:32 PM
1458708821-rfc4226.pdf (Size: 100.3 KB / Downloads: 5)
HOTP Algorithm December 2005
1. Overview
The document introduces first the context around an algorithm that
generates one-time password values based on HMAC [BCK1] and, thus, is
named the HMAC-Based One-Time Password (HOTP) algorithm. In Section
4, the algorithm requirements are listed and in Section 5, the HOTP
algorithm is described. Sections 6 and 7 focus on the algorithm
security. Section 8 proposes some extensions and improvements, and
Section 10 concludes this document. In Appendix A, the interested
reader will find a detailed, full-fledged analysis of the algorithm
security: an idealized version of the algorithm is evaluated, and
then the HOTP algorithm security is analyzed.
2. Introduction
Today, deployment of two-factor authentication remains extremely
limited in scope and scale. Despite increasingly higher levels of
threats and attacks, most Internet applications still rely on weak
authentication schemes for policing user access. The lack of
interoperability among hardware and software technology vendors has
been a limiting factor in the adoption of two-factor authentication
technology. In particular, the absence of open specifications has
led to solutions where hardware and software components are tightly
coupled through proprietary technology, resulting in high-cost
solutions, poor adoption, and limited innovation.
In the last two years, the rapid rise of network threats has exposed
the inadequacies of static passwords as the primary mean of
authentication on the Internet. At the same time, the current
approach that requires an end user to carry an expensive, single-
function device that is only used to authenticate to the network is
clearly not the right answer. For two-factor authentication to
propagate on the Internet, it will have to be embedded in more
flexible devices that can work across a wide range of applications.
The ability to embed this base technology while ensuring broad
interoperability requires that it be made freely available to the
broad technical community of hardware and software developers. Only
an open-system approach will ensure that basic two-factor
authentication primitives can be built into the next generation of
consumer devices such as USB mass storage devices, IP phones, and
personal digital assistants.
One-Time Password is certainly one of the simplest and most popular
forms of two-factor authentication for securing network access. For
example, in large enterprises, Virtual Private Network access often
requires the use of One-Time Password tokens for remote user
authentication. One-Time Passwords are often preferred to stronger
forms of authentication such as Public-Key Infrastructure (PKI) or
biometrics because an air-gap device does not require the
installation of any client desktop software on the user machine,
therefore allowing them to roam across multiple machines including
home computers, kiosks, and personal digital assistants.
This document proposes a simple One-Time Password algorithm that can
be implemented by any hardware manufacturer or software developer to
create interoperable authentication devices and software agents. The
algorithm is event-based so that it can be embedded in high-volume
devices such as Java smart cards, USB dongles, and GSM SIM cards.
The presented algorithm is made freely available to the developer
community under the terms and conditions of the IETF Intellectual
Property Rights [RFC3979].
The authors of this document are members of the Open AuTHentication
initiative [OATH]. The initiative was created in 2004 to facilitate
collaboration among strong authentication technology providers.
3. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
4. Algorithm Requirements
This section presents the main requirements that drove this algorithm
design. A lot of emphasis was placed on end-consumer usability as
well as the ability for the algorithm to be implemented by low-cost
hardware that may provide minimal user interface capabilities. In
particular, the ability to embed the algorithm into high-volume SIM
and Java cards was a fundamental prerequisite.
R1 - The algorithm MUST be sequence- or counter-based: one of the
goals is to have the HOTP algorithm embedded in high-volume devices
such as Java smart cards, USB dongles, and GSM SIM cards.
R2 - The algorithm SHOULD be economical to implement in hardware by
minimizing requirements on battery, number of buttons, computational
horsepower, and size of LCD display.
R3 - The algorithm MUST work with tokens that do not support any
numeric input, but MAY also be used with more sophisticated devices
such as secure PIN-pads.
R4 - The value displayed on the token MUST be easily read and entered
by the user: This requires the HOTP value to be of reasonable length.
The HOTP value must be at least a 6-digit value. It is also
desirable that the HOTP value be ’numeric only’ so that it can be
easily entered on restricted devices such as phones.
R5 - There MUST be user-friendly mechanisms available to
resynchronize the counter. Section 7.4 and Appendix E.4 details the
resynchronization mechanism proposed in this document
R6 - The algorithm MUST use a strong shared secret. The length of
the shared secret MUST be at least 128 bits. This document
RECOMMENDs a shared secret length of 160 bits.
5. HOTP Algorithm
In this section, we introduce the notation and describe the HOTP
algorithm basic blocks -- the base function to compute an HMAC-SHA-1
value and the truncation method to extract an HOTP value.
5.1. Notation and Symbols
A string always means a binary string, meaning a sequence of zeros
and ones.
If s is a string, then |s| denotes its length.
If n is a number, then |n| denotes its absolute value.
If s is a string, then s[i] denotes its i-th bit. We start numbering
the bits at 0, so s = s[0]s[1]...s[n-1] where n = |s| is the length
of s.
Let StToNum (String to Number) denote the function that as input a
string s returns the number whose binary representation is s. (For
example, StToNum(110) = 6.)
Here is a list of symbols used in this document.
Symbol Represents
C 8-byte counter value, the moving factor. This counter
MUST be synchronized between the HOTP generator (client)
and the HOTP validator (server).
K shared secret between client and server; each HOTP
generator has a different and unique secret K.
T throttling parameter: the server will refuse connections
from a user after T unsuccessful authentication attempts.
resynchronization parameter: the server will attempt to
verify a received authenticator across s consecutive
counter values.
Digit number of digits in an HOTP value; system parameter.
5.2. Description
The HOTP algorithm is based on an increasing counter value and a
static symmetric key known only to the token and the validation
service. In order to create the HOTP value, we will use the HMAC-
SHA-1 algorithm, as defined in RFC 2104 [BCK2].
As the output of the HMAC-SHA-1 calculation is 160 bits, we must
truncate this value to something that can be easily entered by a
user.
HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))
Where:
- Truncate represents the function that converts an HMAC-SHA-1
value into an HOTP value as defined in Section 5.3.
The Key (K), the Counter ©, and Data values are hashed high-order
byte first.
The HOTP values generated by the HOTP generator are treated as big
endian.
5.3. Generating an HOTP Value
We can describe the operations in 3 distinct steps:
Step 1: Generate an HMAC-SHA-1 value Let HS = HMAC-SHA-1(K,C) // HS
is a 20-byte string
Step 2: Generate a 4-byte string (Dynamic Truncation)
Let Sbits = DT(HS) // DT, defined below,
// returns a 31-bit string
Step 3: Compute an HOTP value
Let Snum = StToNum(Sbits) // Convert S to a number in
0...2^{31}-1
Return D = Snum mod 10^Digit // D is a number in the range
0...10^{Digit}-1