openswan协商流程之（六）：main_inI3_outR3()

主模式第六包：main_inI3_outR3

1. 序言

main_inI3_outR3()函数是ISAKMP协商过程中第六包的核心处理函数的入口，第五六包主要用来验证对方的身份信息，同时此报文也是加密后的报文。这里我们主要说明main_inI3_outR3的函数调用关系、处理流程以及对源码的注释分析，关于main_inI3_outR3的上下文环境暂不叙述，留给后面的文章进行更新。

ISAKMP协商报文的处理流程都比较复杂，此函数在协商的报文处理函数中比较复杂的，因此个人学习期间难免有遗漏和理解错误的地方，请大家多多批评指正。

---

目前主要是整理源码中的处理里流程和实现逻辑，尚未深入比较细节的处理；后续在我整理完毕使用主模式协商的9个报文后，我再次结合代码整理每一个报文的详细流程，到时把每一个报文的注意事项、作用，处理方式做一个整体上的把握。同时结合书本上的描述来解释代码层的实现。

---

第五六个报文的载荷内容如下：
在这里插入图片描述:

2.函数调用关系

略。

3. 第六个报文流程图

第六个报文的处理流程可以分为三类：

• 解析对方的身份标识(ID)和证书载荷，匹配对方的身份标识
• 身份验证
  • 预共享秘钥
  • 数字证书
• 构建应答报文
  • 身份标识
  • 证书载荷
  • 对数据包进行签名
  • 加密

流程图下图：

4. main_inI3_outR3_tail源码学习

因为main_inI3_outR3中直接调用了main_inI3_outR3_tail, 故而直接将main_inI3_outR3_tail的源代码进行说明，而不再介绍main_inI3_outR3。

该函数的是第六包的核心处理函数，它中调用了main_id_and_auth()完成了对方的ID载荷、证书载荷等的解析和认证工作。

在认证成功的前提下，在继续构建自已的应答报文，将自己的身份标识、证书、签名值等载荷封装然后对报文进行加密，最后发送给隧道的发起者。

static stf_status
main_inI3_outR3_tail(struct msg_digest *md
, struct key_continuation *kc)
{
   
   
    struct state *const st = md->st;
    u_int8_t auth_payload;
    pb_stream r_id_pbs;	/* ID Payload; also used for hash calculation */
    cert_t mycert;
    bool send_cert;
    unsigned int np;

    /* ID and HASH_I or SIG_I in
     * Note: this may switch the connection being used!
     */
    {
   
   
	stf_status r = main_id_and_auth(md, FALSE
					, main_inI3_outR3_continue
					, kc);

	if (r != STF_OK)
	    return r;
    }

    /* send certificate if we have one and auth is RSA */
    mycert = st->st_connection->spd.this.cert;

    send_cert = st->st_oakley.auth == OAKLEY_RSA_SIG
	&& mycert.type != CERT_NONE
	&& ((st->st_connection->spd.this.sendcert == cert_sendifasked
	     && st->hidden_variables.st_got_certrequest)
	    || st->st_connection->spd.this.sendcert==cert_alwayssend);

    doi_log_cert_thinking(md
			  , st->st_oakley.auth
			  , mycert.type
			  , st->st_connection->spd.this.sendcert
			  , st->hidden_variables.st_got_certrequest
			  , send_cert);

    /*************** build output packet HDR*;IDir;HASH/SIG_R ***************/
    /* proccess_packet() would automatically generate the HDR*
     * payload if smc->first_out_payload is not ISAKMP_NEXT_NONE.
     * We don't do this because we wish there to be no partially
     * built output packet if we need to suspend for asynch DNS.
     */
    /* ??? NOTE: this is almost the same as main_inR2_outI3's code */

    /* HDR* out
     * If auth were PKE_AUTH or RPKE_AUTH, ISAKMP_NEXT_HASH would
     * be first payload.
     */
    echo_hdr(md, TRUE, ISAKMP_NEXT_ID);/*回转数据包头;*/

    auth_payload = st->st_oakley.auth == OAKLEY_PRESHARED_KEY
	? ISAKMP_NEXT_HASH : ISAKMP_NEXT_SIG;

    /* IDir out *//*添加ID载荷*/
    {
   
   
	/* id_hd should be struct isakmp_id, but struct isakmp_ipsec_id
	 * allows build_id_payload() to work for both phases.
	 */
		struct isakmp_ipsec_id id_hd;
		chunk_t id_b;

		build_id_payload(&id_hd, &id_b,