组织：中国互动出版网（www.china-pub/）
RFC文档中文翻译计划（www.china-pub/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub
译者：张海斌（netdebug    internetdebug@elong ）
译文发布时间：2002-01-31
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
Network Working Group                                        N. Haller
Request for Comments: 2289                                    Bellcore
Obsoletes: 1938                                                C. Metz
Category: Standards Track                  Kaman Sciences Corporation
P. Nesser
Nesser & Nesser Consulting
M. Straw
Bellcore
February 1998
一次口令系统
A One-Time Password System
备忘录状况
这份文档为Internet社区指定为Internet标准（轨迹）协议，并且为进一步改进需要讨论和建议。这份协议的标准化状态和状况请参阅"Internet官方协议标准（Internet Official Protocol Standards ）"(STD 1)的当前版。这份备忘录的分发不受限制。
版权声明
Copyright (C) The Internet Society (1998).  版权所有.
目录
目录 2
0.译者的话 2
1.0 摘要 3
2.0 概述 3
3.0 介绍 3
4.0 需求术语 4
5.0 安全哈希函数（SECURE HASH FUNCTION） 4
6.0 一次口令的产生 5
7.0 一次口令的验证 7
8.0 一次口令更改 7
9.0 避免竞争攻击 8
10.0 安全考虑 9
11.0 确认 9
12.0 参考文献 9
13.0 作者的地址 10
附录 A  -  安全哈希算法界面 11
附录 B  -  可替换字典算法 13
附录 C  -  OTP认证例子 14
附录 D - 六词和二进制格式之间转换的字典 17
完整版权声明 23
0.译者的话
译者在翻译这份文档的时候，采取直译的方式，尽量保证原文的原意。同时也尽量考虑了中文的语义顺畅，便于中文读者阅读，译者在译文中加入了一些修饰语和译注，修饰语一般在括号中写明，而译注均有“译者注”字样。由于译者翻译本篇文挡时间有限，译文中一定会存在许多理解有误、用词不当之处，欢迎读者来信指正，共同学习。
1.0 摘要
这篇文档描述一次口令认证系统（one-time password authentication system）(OTP)。系统提供对系统访问（login）的认证以及针对基于重放获取可再用口令（replaying captured reusable passwords）之上的被动攻击的安全认证需求的其他应用。OPT从S/KEY 演化而来（S/KEY是Bellcore的商标）。一次口令系统被Bellcore（贝尔通讯研究所）释放，在
参考[3]和[5]中描述。
译者注：one-time password称为一次性口令，在本文中称为一次口令。
2.0 概述
一种互联网计算系统的攻击形式是监听网络连接以获得认证信息，例如合法用户的登录IDs和口令。一旦这个信息被捕获，它就能获得用于以后对系统的访问（权）。一次口令系统被设计为还击这种攻击类
型，称作“重播攻击”[4]（"replay attack"）。
在本文档中描述的认证系统使用一秘密通行短语（pass-phrase）去衍生一系列一次口令（单独使用的）。使用这个系统，用户的秘密通行短语任何时候（例如认证过程中或者通行短语更改过程中）都不在网络中传输。因此，对重放攻击是非脆弱的。附加的安全通过无秘密信息需要被存储在任何系统中的特征被提供，包括被保护的服务。
OTP系统避免针对认证子系统受到外部被动攻击的危害。它不能阻止网络监听去获得私有信息的存取以及不能提供避免或者“社会工程”（"social engineering"）或者主动攻击（active attacks）[9]的危害的保护。
3.0 介绍
在OPT一次口令系统的操作中存在两个实体。发起者（generator）必须从用户的秘密通行短语和从服务的质疑（challenge）中提供的信息产生适当的一次口令。服务必须发送包括给发起者适当的产生参数的质疑，必须验证接收的一次口令，必须存储接收到的最近有效的一次口令，以及必须存储相应的一次口令序列数（sequence number）。同时服务必须也便于以安全的方式对用户的秘密通行短语的改变。
OTP系统发起者传送用户的秘密通行短语，随后接收到从服务质疑的一部分的（随机）种子（seed），
通过安全哈希函数（hash function）多次叠代运算产生一个一次口令。每一次成功的验证之后，安全哈希函数叠代的次数减少1。这样，唯一序列的口令产生了。服务通过计算安全哈希函数一次和比较先前从发起者接收到的一次口令来验证发起者的一次口令。这个技术由Leslie Lamport [1]第一次提出。
4.0 需求术语
在这篇文档中，用于定义每一个特殊需求的重要意义的词通常大写。这些词是：
- MUST
这个词或者形容词"REQUIRED"表示这项是具体指定的绝对需求。
- SHOULD
这个词或者形容词"RECOMMENDED"表示在特定的环境中存在有效的理由去忽略这项，但是完整的含义应该被理解以及在做出不同的进程之前要仔细衡量。
- MAY
这个词或者形容词"OPTIONAL"表示这项是真正可选的。例如，一个销售商可以选择包括这项，因为市场的需求或者增强产品（的功能）；而另一个销售商可以忽略同一个选项。
5.0 安全哈希函数（SECURE HASH FUNCTIO
N）
OTP系统的安全依赖于安全哈希函数的不可逆性。这样的函数必须是正向易于计算的，但是反过来计算不可行。
这里有三个这样的哈希算法接口被定义，Ronald Rivest 的MD4 [2]和MD5 [6]，以及NIST 的SHA [7]。所有服务和发起者之间一致的工具必须（MUST）支持MD5。他们应该（SHOULD）支持SHA和可以（MAY）也支持MD4。明显的，发起者和服务之间为了互操作必须使用同样的算法。其他哈希算法可以通过公开适当的接口为这个系统的使用具体指定。
上面列出的安全哈希算法有其可以接收任意长度的输入和产生固定大小输出的特性。OPT系统使用附录A中定义的算法将输出折叠为64 bit。64 bit也是一次口令的长度。当必要时这个程度可以确认对安全是足够长的以及对于手工输入是足够短的（参见下面，输出的格式）。
6.0 一次口令的产生
这部分描述一次口令的产生。这个处理过程由所有输入被组合在一起的初始化步骤、安全哈希函数被应用指定次数的运算步骤，和64 bit一次口令被转化为人类可读格式的输出函数组成。
附录C包含给定输入的集合的输出例子。它提供了证实这些算法应用的表达实现。
初始化步骤
原则上，用户的安全通行短语可以是任何长度。为了减少来自例如穷举搜索或者字典攻击的危险，通讯短语字符串必须（MUST）至少包含10个字符（参见下面的输入格式）。所有工具必须（MUST）支持至少63个字符的通行短语。安全通行短语通常，但不被要求，是由用户提供的原文信息。
在这个步骤中，通行短语与从服务方以明文方式传递过来的种子（seed）连接在一起。这个非安全（non-secret）种子允许客户在多个机器上（使用不同的种子）使用同样的安全通行短语以及通过改变种子安全地再循环使用他们的安全通行短语。
这个连接的结果通过使用附录A中列举的安全哈希函数算法之一，然后产生64 bit输出。
计算步骤
一系列一次口令通过应用对初始化步骤（称为S）的输出多次安全哈希函数运算产生。也就说，第一个一次口令通过将S传递到由用户指定次数（N次）的安全哈希函数运算产生。下一个一次口令通过传递S到安全哈希函数N-1次运算产生。监视一次口令传输的监听者不能产生下一个需要的口令，因为要做到这些就意味着哈希函数的逆运算。
输入的格式
安全通行短语仅被OTP发起者看到。为了允许发起者之间的可交互性，所有的发起者必须（MUST）支持10到63字符长度的安全通行短语。执行工具可以（MAY）支持更长的通行短语，但是这样的工具存在与仅支持短通行短语的工具之间失去交互
性。
种子必须（MUST）由纯正的字母数字字符（alphanumeric characters）组成以及在长度上为16字符长。种子是一串必须（MUST）不能包含空格（blanks）和应该由严格的从来自ISO-646内部编码集合（ISO-646 Invariant Code Set）的字母数字字符组成的字符串。种子必须（MUST）是大小写无关的以及必须（MUST）是在处理之前内部转换为小写。
序列号和种子一起组成一个大的数据单元称为挑战（challenge）。挑战作为从安全通行短语计算正确的一次口令需要的参数提供给发起者。挑战必须（MUST）是标准语法以便自动产生在上下文中能识别的挑战以及提取这些参数。挑战的语法如下：
otp-<algorithm identifier> <sequence integer> <seed>
三个标志段（tokens）必须（MUST）以空格分开(可以定义为任何数量的空格和/或制表符tabs)和整个
挑战字符串必须（MUST）以或者是空格或者一新行结束。字符串"otp-"必须（MUST）为小写。算法标识符是大小写敏感的(已知存在的标识符都是小写)，以及种子是大小写不敏感的并且在使用之前转换为小写。如果额外的算法被定义，适当的标识符(短的，但是没有限制为三或者四个字符)必须被定义。当前定义的算法标识符是：
md4        MD4 Message Digest
md5        MD5 Message Digest
sha1      NIST Secure Hash Algorithm Revision 1
一个OTP挑战例子是：otp-md5 487 dog2
输出的格式
上面处理过程产生的一次口令在长度上为64 bit。输入一个64 bit数字是困难的并且容易出错的过程。 一些产生器插入口令到输入流中和另外一些对于“剪切和粘贴”的系统使其有效。仍然有一些其他的布置（arrangements）需要一次口令手工输入。OTP系统设计为易于手工输入而没有妨碍自动的方法。因此一次口令可以（MAY）转换为，和所有服务必须（MUST）有能力接受的，仅使用从ISO-646 IVCS字符集中的六个（1到4个字母letter）简单类型词（word）的序列。每个词从2048个词的字典中选取；每个
种子哈希转换链接词为11bit，所有一次口令可以被编码。
在这个编码中两个附加位（bits）用于存储校验和（checksum）。密钥的64 bits被分裂为一对bits，然后这些对（pairs）被加和在一起。 这个和（sum）的两个最低有效位在随着和（sum）的最低有效位作为最低位编码的六词（word）序列的最后两位（bits）被编码。所有OTP产生器必须（MUST）计算这个校验和以及所有OTP服务必须（MUST）作为解码（decoding）这个一次口令的代表操作的一个部分显式的验证这个校验和。
产生六词格式（six-word format）的产生器必须（MUST）以单空格作为分隔的大写形式展示。所有服务必须（MUST）接受六词格式
而忽略大小写和用作分隔的空格。下面两行表示同一个一次口令。第一行作为从产生器输出和服务的输入是有效的，第二行仅作为手工输入到服务是有效的。
OUST COAT FOAL MUG BEAK TOTE
oust coat foal  mug  beak  tote
互操作要求所有的OTP服务和产生器使用相同的字典。标准字典起初在其描述在RFC 1760 [5]中的"S/KEY One Time Password System"明确指定。
为了便于小的产生器的实现（implementation），对于一次口令的表示十六进制输出是一个可选择的表示。所有服务软件的实现必须（MUST）接受同六词格式一样的大小写不敏感的十六进制（数字）。十六进制数字可以由空格分隔，所以服务要求（REQUIRED）忽略所有的空格。如果表示是通过空格分开的，首位的零必须保留。十六进制格式的例子如下：
Representation（表示）        Value（值）
3503785b369cda8b              0x3503785b369cda8b
e5cc a1b8 7c13 096b          0xe5cca1b87c13096b
C7 48 90 F4 27 7B A1 CF      0xc74890f4277ba1cf
47 9 A68 28 4C 9D 0 1BC      0x479a68284c9d01bc
除了接受六词和十六进制的64 bit一次口令编码之外，服务应该（SHOULD）接受在附录B中描述的可替换的字典编码。在这个编码中的六个词一定（MUST）不能与在标准字典词的集合中重叠（overlap）。为了避免十六进制表示的含糊不清（ambiguity），在可替换字典中的词必须（MUST）不能仅由字母A-F构成。这样编码的解码词不需要任何可替换字典使用的知识，所以任何可选字典的可接受暗含着所有字典的可接受。在可替换字典中的词是大小写敏感的。产生器和服务必须（MUST）在处理这些词的过
程中保护大小写。
总的来说，所有兼容的服务必须（MUST）接受使用标准字典（RFC 1760 和附录D）的六词输入，必须（MUST）接受十六进制编码，和应该（SHOULD）接受使用可替代字典技术（Alternative Dictionary technique）（附录B）的六词输入。一次口令的十六进制编码看上去像一个有效的六词标准字典编码是有很小的可能性的，所有工具（implementations）必须（MUST）使用下列模式（scheme），如果一个六词编码的一次口令是有效的，它被接受。否则如果一次口令可以作为十六进制被解释，和编码是有效的，那么它被接受。
7.0 一次口令的验证
正如上文描述的一个期望OTP验证需求的服务系统的应用发送一个OTP挑战。从这个挑战和安全通行短语给定参数，发起者能计算（或者查）通过服务被验证的一次口令。
服务系统有一个数据库，包含每一个用户，从最后成功验证的一次口令或者新近初始化的第一个OTP序列。为了验证用

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。