[secdir] Secdir review of draft-ietf-hip-rfc5203-bis-09

"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Mon, 28 December 2015 10:06 UTC

Return-Path: <takeshi_takahashi@nict.go.jp>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6F7551A8AE0; Mon, 28 Dec 2015 02:06:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.298
X-Spam-Level: ***
X-Spam-Status: No, score=3.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id O5l45G8_2efM; Mon, 28 Dec 2015 02:06:38 -0800 (PST)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B4E1A8ADF; Mon, 28 Dec 2015 02:06:37 -0800 (PST)
Received: from gw1.nict.go.jp (gw1.nict.go.jp []) by ns1.nict.go.jp with ESMTP id tBSA6Z6B053880; Mon, 28 Dec 2015 19:06:35 +0900 (JST)
Received: from mail2.nict.go.jp (mail2.nict.go.jp []) by gw1.nict.go.jp with ESMTP id tBSA6Zoi053876; Mon, 28 Dec 2015 19:06:35 +0900 (JST)
Received: from VAIO (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.nict.go.jp (NICT Mail Spool Server2) with ESMTPS id 7533D4F50; Mon, 28 Dec 2015 19:06:35 +0900 (JST)
From: "Takeshi Takahashi" <takeshi_takahashi@nict.go.jp>
To: <draft-ietf-hip-rfc523-bis.all@tools.ietf.org>
Date: Mon, 28 Dec 2015 19:06:37 +0900
Message-ID: <000901d14157$7052a680$50f7f380$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdFBV2tdjpEObS8/TWObnkWo9KTB5g==
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.7 at zenith1
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/4KO8iiFTIlDBNk5Kds4Qw80JHbk>
Cc: iesg@ietf.org, hip-chairs@tools.ietf.org, secdir@ietf.org
Subject: [secdir] Secdir review of draft-ietf-hip-rfc5203-bis-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Dec 2015 10:06:39 -0000


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
Document editors and WG chairs should treat these comments just like any
other last call comments.

[overall feeling on this draft]

ready, and good to proceed


This draft updates RFC 5203 to cope with HIPv2 (RFC 7401).
RFC 5203 specifies a registration mechanism for HIPv1 (RFC 5201).
Likewiise, this draft specifies the mechanism for HIPv2.


Below are simply clarification questions, and these do not block the further
process of this document.
I am not that familiar with HIP, so it would be helpful if you could provide
me some comments on them to deepen my understanding.

1. "If the requester has one or more suitable certificates, the host SHOULD
include them (or just the most suitable one)"(in section 3.3)

I wonder whether it would be better to let the requester send only the most
suitable certificate.
The requester may send multiple certificates, but it would be helpful if the
requester sends only the most suitable certificate, I guess. (It is easy to
process from the standpoint of the receiver, isn't it?)
Would you explain why the draft encourages to send multiple certificates
rather than sending only the most suitable certificate?

2. "it SHOULD send the registration request without the CERT parameter to
test whether the registrar accepts the request based on the host's
identity." (in Section 3.3)

In this situation, if a malicious party knows the identity of the reqester,
the party can get the access right.
Is the identity protected so that no malicious party can get it?

3. "Other documents will define specific values for registration types. See
Section 7 for more information" (Section 4.3)

I looked at Section 7 to understaind the types and values of Reg Type, but I
guess the section does not define any on them.
Are the types and values completely the same as the ones defined by RFC

4. "Insufficient resource" and "Invalid certificate" (in the table in
Section 7)
When a requester sends requests without sending CERT parameters, the
requester expects to be authenticated based on its identity.
But sometimes it fails.
In this case, which of the failor type will be used? "Insufficient
resources"? or "Invalid certificate"? or none of them?

Thank you for your kind contributions.