rfc2367.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：（  ）
译文发布时间：2002-1-9
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。




Network Working Group                                       D. McDonald
Request for Comments: 2367                                      C. Metz
Category: Informational                                         B. Phan
                                                              July 1998


PF_KEY Key Management API, Version 2
（RFC2367——PF_KEY Key Management API, Version 2）

本备忘录状态

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

版权声明

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

摘要

       本文档提出的通用密钥管理API不但为IP安全[Atk95a][Atk95b][Atk95c]而且
   为其它网络安全提供服务。做为可以自由发布和使用的美国海军研究实验室设计实
   现的IPv6和IPsec的一部分，在4.4-Lite BSD内部实现了这个API的第一版。这里编
   辑成档有助于其他人采用这个API，这些规定增强了密钥管理应用程序的可移植性(
   例如：手工设置程序，ISAKMP守护进程，GKMP守护进程，Photuris守护进程或者SKIP
   证书发现协议守护进程)。

目录

1 介绍	3
1.1 术语	3
1.2 总体模型	4
1.3 PF_KEY套接口定义	6
1.4 PF_KEY消息行为概述	7
1.5 共同的PF_KEY操作	7
1.6 PF_KEY和PF_ROUTE之间的区别	8
1.7 名称空间	8
1.8 手工密钥	9
2. PF_KEY消息格式	9
2.1 基本消息头格式	9
2.2 消息头位对齐和扩展头	11
2.3 附加的消息域	11
2.4 消息格式的图例	22
3 符号名	26
3.1 消息类型	26
3.2 安全关联标志	35
3.3 安全关联状态	35
3.4 安全关联类型	36
3.5 算法类型	37
3.6 扩展头值	37
3.7 身份扩展值	38
3.8 敏感度扩展值	39
3.9 提议扩展值	39
4 发展趋势	39
5. 实例	40
5.1 简单的IP安全例子	40
5.2 代理IP安全例子	42
5.3 OSPF安全例子	44
5.4 其它	45
6 安全考虑	45
致谢	46
参考	46
放弃声明	48
作者地址	48
附录A：混杂模式发送/接收消息扩展	49
附录B：被动转换消息扩展	50
附录C：密钥管理专用数据扩展	51
附录D：头文件样本	52
附录E：修改记录	57
附录F：版权声明	60



1 介绍
       PF_KEY是一个新的套接口协议族，用于可信赖的有特权的密钥管理程序和操作
   系统内部的密钥管理(这里指“密钥引擎”或者安全关联数据库(SADB))的通信。密
   钥引擎和它的构件是一个会话安全属性的具体表现，也是“安全关联”的实例。“
   安全关联”(SA)的概念在RFC2401(原文为RFC1825现已被代替)中说明。这里所说的
   PF_KEY和密钥引擎引用多于加密密钥，传统术语“密钥管理”为了一致性予以保留。

       PF_KEY源于BSD的路由套接字PF_ROUTE([Skl91])的一部分。本文档说明了PF_KEY
   的第二版本。第一版本为4.4-Lite BSD UNIX和Cisco ISAKMP/Oakley密钥管理守护
   进程在NRL IPv6+IPsec Software Distribution的最初的五个alpha测试版中实现。
   版本2扩充和精制了接口。理论上，本文档定义的消息可以在无套接口的环境应用(
   例如：在两个直接通信的应用层程序之间)，但是这种可能性这里不做详细讨论。

       安全策略在这个接口中慎重地忽略。PF_KEY不是协调全系统安全策略的机制，
   也不想要实施任何密钥管理策略。PF_KEY的开发者认为把安全机制(如PF_KEY)和安
   全策略分离是很重要的，这样允许一个机制很容易的支持多个策略。


1.1 术语

       尽管本文档不打算成为实际的因特网标准，本接口用来说明独特功能的重要性
   的关键词通常大写。这些词中的一部分，包括MUST, MAY和SHOULD在文档RFC2119中
   详细说明。

   - 一致和符合

       一致和符合在本规范中具有相同的含义。无论在那种情形，强制执行或者MUST
   指定的条款必须完全贯彻。如果任一强制条款没有贯彻，那么具体实现就不符合本
   规范。

       本规范也使用很多通常在网络安全方面使用的术语，其它文档提供了很多定义
   和背景资料[VK83, HA94, Atk95a]。两个术语在这里专门提及：

   - (加密/认证)算法

       PF_KEY的目的是指一个算法无论是加密还是认证，包含一系列完成SA类型所指
   出的数据包加密或认证的操作。一个PF_KEY算法可以由多个加密算法构成。另一种
   可能，同一基本加密算法可以应用于不同的操作模式或者一些其它不同的实现。这
   些区别，今后命名为“_算法识别码_”，以区别不同的PF_KEY算法和同一算法的选
   项。算法识别码将导致根本不同的安全性质。

       例如，DES和3DES使用相同的加密算法，但是它们用法不同并且具有不同的安
   全性质。DES的三次应用被认为是一个算法识别，因此分为PF_KEY算法DES和3DES。
   Keyed-MD5和HMAC-MD5使用相同的散列函数，但是构成它们的消息认证编码不同，
   HAMC的用途就是一个算法识别码。DES-ECB和DES-CBC是相同的加密算法，但是使用
   不同的模式。模式(例如：链式对编码书)就是一个算法识别。然而，128位密钥的
   Blowfish与384位密钥的Blowfish相似，因为除了算法的工作方式其它相同，因此
   密钥长度不是算法识别码。

       在IP安全方面，一个首要规则就是无论什么标记“加密”于ESP变换的部分可
   能就是一个PF_KEY加密算法；无论什么标记“认证”于AH或者ESP变换的部分可能
   就是一个PF_KEY认证算法。


1.2 总体模型

       这一节描述实现PF_KEY密钥管理应用程序接口的操作系统的总体模型。这一节
   将要提供有用的背景资料以便理解本文档的其余部分。总体模型的介绍不会强迫一
   个PF_KEY具体实现严格遵循这一小节讨论的概念上的组件。

       大多数密钥管理通常部分或者全部在应用层实现。例如：IPsec的密钥管理提
   案ISAKMP/Oakley、 GKMP和Photuris都是应用层协议；手动调节也是在应用层完成；
   甚至部分SKIP协议层密钥管理提案能够在应用层实现。图1说明了密钥管理守护进
   程和PF_KEY之间的关系。密钥管理守护进程使用PF_KEY与密钥引擎通信，并且使用
   PF_INET（在IPv6下用PF_INET6）通过网络与远端的密钥管理程序通信。

       “密钥引擎”或者“安全关联数据库（SADB）”在内核是一个逻辑实体，可以
   为不同的安全协议存储、更新和删除安全关联数据。内核中的安全协议（例如：IP
   Security、aka IPsec）利用内核内部的逻辑接口请求并且获得安全关联。

       在IPsec的情况下，如果按照策略一个特殊的输出包需要处理，IPsec通过内核
   内部接口从密钥引擎请求一个合适的安全关联；如果密钥引擎有一个合适的SA就分
   配给IPsec使用；如果密钥引擎没有，但是密钥管理程序已经预先指出（通过PF_KEY
   SADB_REGISTER消息）了IPsec可以获得的安全关联簇，那么密钥引擎请求并建立一个
   安全关联（通过PF_KEY SADB_ACQUIRE消息）。当密钥管理守护进程建立一个新的安全
   关联就会保存在密钥引擎中以备将来使用。


                     +----------------+
                     |密钥管理守护进程|
                     +----------------+
                       |           |
                       |           |
                       |           |                   应用程序
               ======[PF_KEY]====[PF_INET]==========================
                       |           |                   系统内核
               +------------+   +-----------------+
               |  密钥引擎  |   |     TCP/IP      |
               |    或者    |---|      包括       |
               |    SADB    |   |     IPsec       |
               +------------+   +-----------------+
                                        |
                                   +----------+
                                   | 网络接口 |
                                   +----------+

              图1: 密钥关联程序和PF_KEY的关系


       为了获得好的性能，一些安全协议（如：IP安全）通常会在操作系统内核中实
   现。其它的安全协议（如：OSPFv2密码认证）在内核外可信的特权程序中实现。图
   2说明了一个可信的特权路由守护进程使用PF_INET同远端路由守护进程传递路由信
   息，并且使用PF_KEY请求、获得和删除路由协议使用的安全关联。


                     +---------------+
                     |  路由守护进程 |
                     +---------------+
                       |           |
                       |           |
                       |           |                   应用程序
               ======[PF_KEY]====[PF_INET]==========================
                       |           |                   系统内核
               +------------+   +-----------------+
               |  密钥引擎  |   |                 |
               |    或者    |---|     TCP/IP      |
               |    SADB    |   |                 |
               +------------+   +-----------------+
                                        |
                                   +----------+
                                   | 网络接口 |
                                   +----------+

        图2: 可信的程序和PF_KEY的关系


       当一个在自身内部实现安全协议的可信的特权程序使用密钥引擎时，操作有所
   不同。在这种情况下，当程序需要安全关联时向密钥引擎发送一个PF_KEY SADB_ACQUIRE
   消息，密钥引擎返回错误或者发送同样的SADB_ACQUIRE消息到一个或者多个可以建
   立所需安全关联的密钥管理程序。如以前，密钥管理守护进程把安全关联存储在密
   钥引擎，可信的特权程序使用一个SADB_GET消息获得安全关联。

       在一些实现中，策略可能在用户层实现，尽管如此，实际的加密处理还是在内
   核发生。这样，策略通信在内核之间，并且用户层策略可以通过PF_KEY扩展实现，
   或者其它类似机制。本文档对这样扩展不做详细说明。本文档规定的PF_KEY不支持
   使用PF_KEY配置整个系统的策略。

       不可信的客户端，如：用户的WEB浏览器或者Telnet客户端不需要使用PF_KEY。
   这里没有规定这些不可信客户端程序请求操作系统的安全服务（例如IPsec）的机
   制。出于安全原因，只有可信的特权程序可以打开PF_KEY套接口。


1.3 PF_KEY套接口定义

       PF_KEY协议族定义在<sys/socket.h>中，与其它的协议族同样的风格。应用程
   序使用PF_KEY不能依靠关键字AF_KEY是否可用，但是内核的实现最好定义AF_KEY。

     密钥管理套接字的建立如下：

     #include <sys/types.h>
     #include <sys/socket.h>
     #include <net/pfkeyv2.h>

     int s;
     s = socket(PF_KEY, SOCK_RAW, PF_KEY_V2);

       PF_KEY守护进程目前只能支持SOCK_RAW套接字。协议域必须设置为PF_KEY_V2，
   否则将返回错误EPROTONOSUPPORT。只有可信的特权进程能够建立PF_KEY套接字。
   UNIX系统的惯例，特权进程是指用户标识符为零的进程。在分离式工作站（CMWs）
   或者其它声称提供多级安全（MLS）的系统上，一个进程必须拥有“密钥管理特权”
   才能打开PF_KEY套接字[DIA]。当前没有上述特权的MLS系统为了符合本规范必须增
   加上述特权给PF_KEY。一些系统，尤其是在一些流行的个人电脑上，没有普通用户
   的概念。这些系统应该设法限制应用程序访问PF_KEY API。


1.4 PF_KEY消息行为概述

       一个进程使用PF_KEY套接字发送和接受消息与密钥引擎相互作用，通过一系列
   预先定义的消息安全关联信息可以被插入和检索内核的安全关联表。在正常情况下，
   所有正确的消息发送至内核并被返回到包括发送者在内的所有打开的PF_KEY套接字。
   格式错误的消息将会造成错误，一个实现必须在返回消息给合适的监听者之前检查
   消息的正确格式。与路由套接字不同，PF_KEY在返回消息中发送错误，不是write()
   或者send()错误时的错误号字段。PF_KEY消息发送不被保证，尤其在内核或者套接
   字缓存耗尽时，并且消息被丢弃。