Linux——密钥管理Socket

 

缅怀Stevens大师。

最好的参考资料:

1.师从互联网。

2.http://man.cx/pf_key(7p):这个man命令并不是Linux的,应该是BSD的,但原理相同。

3.UNP v1第19章 。

4.http://www.ibm.com/developerworks/cn/linux/l-key-retention.html

http://qq164587043.blog.51cto.com/261469/201152

第一条:概述

人如期名,密钥管理Socket,就是用来管理密钥的(废话^_^)。 

密钥(key)是一组密码学数据、身份验证标记或某些相似的元素,它在内核中由 struct key 表示。在 Linux 内核源代码中,struct key 是在 include/linux/key.h 下定义的。

第二条:密钥管理socket

密钥管理描述符

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

密钥管理消息

所有密钥管理消息都是由头部和可选的扩展数据组成

struct sadb_msg {/* sizeof(struct sadb_msg) == 16 *///头部

 __u8 sadb_msg_version;//PF_KEY_V2

 __u8 sadb_msg_type;//密钥管理消息的类型

 __u8 sadb_msg_errno;//error indication

 __u8 sadb_msg_satype;//SA类型(security association)

 __u16 sadb_msg_len;//length of header(头部) + extensions/8(数据)

 __u16 sadb_msg_reserved;//zero on transmit ,ifnored on received

 __u32 sadb_msg_seq;//sequence number

 __u32 sadb_msg_pid;//process ID of source or dest

} __attribute__((packed));

sadb_msg_type:取值如下

#define SADB_RESERVED 0   

#define SADB_GETSPI 1  /* Get a new SPI value from the system. */分配一个用于创建SADB表项的SPI

#define SADB_UPDATE 2  /* Update an SA. */更改一个不完备的SADB表项

#define SADB_ADD 3  /* Add a fully-formed SA. */增加一个完整的SADB表项

#define SADB_DELETE 4  /* Delete an SA. */删除一个SADB表项

#define SADB_GET 5   /* Get an SA */获取一个SADB表项

#define SADB_ACQUIRE 6   /* Kernel needs a new SA. */请求创建一个SADB表项

#define SADB_REGISTER 7   /* Register to receive ACQUIRE messages. */注册成 SADB_ACQUIRE的应答者

#define SADB_EXPIRE 8    /* SA has expired. */通知某个SADB表项已经期满

#define SADB_FLUSH 9   /* Flush all SAs. */冲刷整个SADB

#define SADB_DUMP 10   /* Get all SAs. (Unreliable) */倾泻出SADB(调试用)

#define SADB_X_PROMISC 11 /* Listen promiscuously */

以上1到10中的10个值只有8是只能由内核发往用户空间,其他9个都可在用户和内核之间双向传递。

sadb_msg_satype:取值如下

/* Security Association types */

#define SADB_SATYPE_UNSPEC 0 //未指明;仅限于请求消息

#define SADB_SATYPE_AH 2  //IPsec安全头部

#define SADB_SATYPE_ESP 3  //IPsec安全净荷封装

#define SADB_SATYPE_RSVP 5  //RSVP认证

#define SADB_SATYPE_OSPFV2 6 // OSPFv2 认证

#define SADB_SATYPE_RIPV2 7  //RIPv2 认证

#define SADB_SATYPE_MIP 8  //可移动IP认证

#define SADB_X_SATYPE_IPCOMP 9 

#define SADB_SATYPE_MAX 9

 

每一种扩展数据类型都有专门对应的数据结构类型:

/* Extension Header values */

#define SADB_EXT_RESERVED 0

1.#define SADB_EXT_SA 1  SA 

对应数据结构:

struct sadb_sa {/* sizeof(struct sadb_sa) == 16 */

 __u16 sadb_sa_len;

 __u16 sadb_sa_exttype;

 __be32 sadb_sa_spi;

 __u8 sadb_sa_replay;

 __u8 sadb_sa_state;

 __u8 sadb_sa_auth;

 __u8 sadb_sa_encrypt;

 __u32 sadb_sa_flags;

} __attribute__((packed));

 

 

2.#define SADB_EXT_LIFETIME_CURRENT 2  SA当前生命期

#define SADB_EXT_LIFETIME_HARD 3  SA生命期硬限制

#define SADB_EXT_LIFETIME_SOFT 4   SA生命期软限制

对应数据结构:

struct sadb_lifetime {/* sizeof(struct sadb_lifetime) == 32 */

__u16 sadb_lifetime_len;

__u16 sadb_lifetime_exttype;

__u32 sadb_lifetime_allocations;

__u64 sadb_lifetime_bytes;

__u64 sadb_lifetime_addtime;

__u64 sadb_lifetime_usetime;

} __attribute__((packed));

3.#define SADB_EXT_ADDRESS_SRC 5   SA宿地址

#define SADB_EXT_ADDRESS_DST 6    SA源地址

#define SADB_EXT_ADDRESS_PROXY 7   SA代理地址

对应数据结构:

struct sadb_address {/* sizeof(struct sadb_address) == 8 */

__u16 sadb_address_len;

__u16 sadb_address_exttype;

__u8 sadb_address_proto;

__u8 sadb_address_prefixlen;

__u16 sadb_address_reserved;

} __attribute__((packed));

 

4.#define SADB_EXT_KEY_AUTH 8  认证密钥

#define SADB_EXT_KEY_ENCRYPT 9  加密密钥

对应数据结构:

struct sadb_key {/* sizeof(struct sadb_key) == 8 */

__u16 sadb_key_len;

__u16 sadb_key_exttype;

__u16 sadb_key_bits;

__u16 sadb_key_reserved;

} __attribute__((packed));

 

5.#define SADB_EXT_IDENTITY_SRC 10 宿身份

#define SADB_EXT_IDENTITY_DST 11  源身份

对应数据结构:

struct sadb_ident {/* sizeof(struct sadb_ident) == 16 */

__u16 sadb_ident_len;

__u16 sadb_ident_exttype;

__u16 sadb_ident_type;

__u16 sadb_ident_reserved;

__u64 sadb_ident_id;

} __attribute__((packed));

 

6.#define SADB_EXT_SENSITIVITY 12   SA敏感性

对应数据结构:

struct sadb_sens {/* sizeof(struct sadb_sens) == 16 */

__u16 sadb_sens_len;

__u16 sadb_sens_exttype;

__u32 sadb_sens_dpd;

__u8 sadb_sens_sens_level;

__u8 sadb_sens_sens_len;

__u8 sadb_sens_integ_level;

__u8 sadb_sens_integ_len;

__u32 sadb_sens_reserved;

} __attribute__((packed));

/* followed by:

__u64 sadb_sens_bitmap[sens_len];

__u64 sadb_integ_bitmap[integ_len];  */

 

7.#define SADB_EXT_PROPOSAL 13   得到提议的情形

对应数据结构:

struct sadb_prop {/* sizeof(struct sadb_prop) == 8 */

__u16 sadb_prop_len;

__u16 sadb_prop_exttype;

__u8 sadb_prop_replay;

__u8 sadb_prop_reserved[3];

} __attribute__((packed));

 

8.#define SADB_EXT_SUPPORTED_AUTH 14   得到支持的认证算法

#define SADB_EXT_SUPPORTED_ENCRYPT 15  得到支持的加密算法

对应数据结构:

struct sadb_supported {/* sizeof(struct sadb_supported) == 8 */

__u16 sadb_supported_len;

__u16 sadb_supported_exttype;

__u32 sadb_supported_reserved;

} __attribute__((packed));

 

 

9.#define SADB_EXT_SPIRANGE 16 可接受的SPI值范围

对应数据结构:

struct sadb_spirange {/* sizeof(struct sadb_spirange) == 16 */

__u16 sadb_spirange_len;

__u16 sadb_spirange_exttype;

__u32 sadb_spirange_min;

__u32 sadb_spirange_max;

__u32 sadb_spirange_reserved;

} __attribute__((packed));

 

 

第三条:RFC2367

 

组织:中国互动出版网(http://www.china-pub.com/)

RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm)

E-mail:ouyang@china-pub.com

译者:(  )

译文发布时间: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消息发送不被保证,尤其在内核或者套接

   字缓存耗尽时,并且消息被丢弃。

 

       一些消息由操作系统产生指出需要那些动作,没必要响应用户的任何消息。这

   样的消息不被所有的PF_KEY套接字接收。这些消息是特定的,因为它们发生在预期

   的频率。同样,一个实现可能更希望限制从内核返回的消息,因为不是所有的PF_KEY

   套接字在同样可信的守护进程中。

 

       许多标准的BSD套接字调用在PF_KEY套接字中没有定义,包括:bind(), connect(),

   socketpair(), accept(),getpeername(), getsockname(), ioctl(), and listen()。

 

 

1.5 共同的PF_KEY操作

 

       将一个新的安全关联加入内核有两种基本途径。最简单的方法是从应用程序发

   送一个包含所有安全关联信息的SADB_ADD消息至内核的密钥引擎。这种方法特别适

   用于手工密钥管理,这对于IPsec和其它安全协议是必需的。

 

       第二种方法是:应用程序首先使用SADB_GETSPI消息从内核请求一个安全参数

   索引(SPI)值,然后发送一个包含安全关联数据的SADB_UPDATE消息消息。这种方

   法适用于密钥管理守护进程,但SPI值需要先于全部安全关联数据获得(这样SPI值

   能够指出密钥管理会话的对端)。

 

       使用SADB_DELETE消息可以删除单个的安全关联;删除一类安全关联或者整个

   内核的安全关联表用SADB_FLUSH消息。

 

       可信的应用层进程(如routed(8)或者gated(8))可以用SADB_GET消息从内核

   的密钥引擎获得一个安全关联(如RIP SA或者OSPF SA)。

 

       内核或者应用层程序可以使用SADB_ACQUIRE消息请求一个某些应用层密钥管理

   进程建立并通过SADB_REGISTER消息在内核登记的安全关联。这个ACQUIRE消息拥有

   一个相关联的序列号。这个序列号必须在随后的SADB_GETSPI、SADB_UPDATE和SADB_ADD

   消息中使用,目的是明了那一个请求获得了它的密钥素材。系列号(下面详述)类

   似于一个远程调用的处理标识符。

 

       当一个安全关联的“软件周期”或者“硬件周期”期满时,从内核发送SADB_EXPIRE

   消息至密钥管理程序。密钥管理程序以收到的SADB_EXPIRE消息中的软件周期为提

   示协商一个替代的安全关联,这样在内核使用之前替代的安全关联已准备好。

 

       SADB_DUMP消息主要是为了PF_KEY实现程序的调试,并且不能用于平常的PF_KEY

   操作。

 

 

1.6 PF_KEY和PF_ROUTE之间的区别

 

       下面指出路由套接字和PF_KEY之间的区别。曾用路由套接字的程序员将会发现

   两者之间的差别。

 

   * PF_KEY消息错误通常在PF_KEY消息中返回,代替说明write()错误的错误号。这

     意味着其它PF_KEY套接字监听者可以知道别的进程的请求失败,这可用于审计。

     这也意味着读PF_KEY消息错误不能做错误检查。

 

     具体实现可以返回write()操作失败导致的EINVAL、ENOMEM和ENOBUFS错误,也可

     以返回错误号。这是最佳处理对于普通错误,这样可以不被其它进程检测到并接

     收错误。应用程序不能依赖于write()调用设置的错误,但是应该检查这些错误,

     并用适当的方式处理。

 

   * 全部消息不是总是有返回消息。SADB_ADD消息就是一个例子。

 

   * PID不是由内核设定。发起消息的进程必须把sadb_msg_pid设置成自己的PID。如

     果内核发起一个消息,sadb_msg_pid必须设置为0。源消息的应答应该有源消息的

     PID(如:内核对SADB_ADD的响应,PID应设置成源SADB_ADD消息的PID值)。

 

 

1.7 名称空间

 

       全部PF_KEYv2预定义和结构定义在头文件<net/pfkeyv2.h>中说明,有一个例

   外:“PF_KEY”(如果包括“AF_KEY”有两个)在头文件<sys/socket.h>中说明。

   所有的PF_KEYv2预定义以前缀“SADB_”开始,所有的结构名以“sadb_”开始,有

   两个例外:“PF_KEY_V2”和“PFKEYV2_REVISION”。

 

       “PFKEYV2_REVISION”是一个日期编码值就像由POSIX和X/Open定义的固定

   值,当前值是199806L,1998是年,06是月份。

 

       本文档没有描述的符号或结构没有作者的明确许可,在<net/pfkeyv2.h>中的

   定义不能使用PF_KEYv2的命名空间,任何本规范没有描述的使用PF_KEYv2名称空间

   的符号或结构必须以“SADB_X_”或“sadb_x_”开始。一个未能遵从这些规则的实

   现是不适应本规范的并且不能有什么要求。这些规则也适用于任何可能包含

<net/pfkeyv2.h>

   的文件。这个规定可以保证实现者不会遇到定义冲突。

 

 

1.8 手工密钥

 

       与4.4-Lite BSD的PF_ROUTE套接口相同,本接口允许一个程序从头到尾完全支

   配内核中的安全关联来实现PF_KEY。PF_KEY的实现必须具有一些手工接口,能提供

   这里描述的PF_KEY接口的所有功能。

 

 

2. PF_KEY消息格式

 

       PF_KEY消息由一个基本的消息头和一些可选的附加数据段组成,附加的数据段

   格式由消息类型决定。

 

       PF_KEY消息目前不要求任何具体非网络的多字节数据段的顺序。除非其它指定

   (如SPI)数据段必须是主机字节序。

 

 

2.1 基本消息头格式

 

       PF_KEY消息由基本消息头和随后的安全关联的具体数据组成,数据段的类型和

   长度由统一的类型长度编码指定。

 

       基本消息头使用POSIX类型,格式如下。为了直观,各字段对齐排列。

 

           struct sadb_msg {

                   uint8_t sadb_msg_version;

                   uint8_t sadb_msg_type;

                   uint8_t sadb_msg_errno;

                   uint8_t sadb_msg_satype;

                   uint16_t sadb_msg_len;

                   uint16_t sadb_msg_reserved;

                   uint32_t sadb_msg_seq;

                   uint32_t sadb_msg_pid;

           };

           /* sizeof(struct sadb_msg) == 16 */

 

   sadb_msg_version

                   PF_KEY消息的版本号,必须设置为PF_KEY_V2。否则,write()调

                   用将失败并报参数错误(EINVAL)。另外,应用程序不能理解从

                   内核收到的消息的格式,运行状态将无法确定。

 

   sadb_msg_type   标识消息的类型。有效的消息类型稍后说明。

 

   sadb_msg_errno  消息的发送者应设置此项为零。如果出现错误,消息的应答者在

          

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值