Re: [secdir] Secdir review of draft-ietf-hip-rfc5203-bis-09
"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Fri, 01 July 2016 10:47 UTC
Return-Path: <takeshi_takahashi@nict.go.jp>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747DB12D56D; Fri, 1 Jul 2016 03:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level:
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrW3UfHxxemk; Fri, 1 Jul 2016 03:47:30 -0700 (PDT)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 723B012D548; Fri, 1 Jul 2016 03:47:27 -0700 (PDT)
Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id u61AlOBL098691; Fri, 1 Jul 2016 19:47:24 +0900 (JST)
Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw2.nict.go.jp with ESMTP id u61AlOfP098687; Fri, 1 Jul 2016 19:47:24 +0900 (JST)
Received: from VAIO (unknown [133.243.30.149]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id 5B77E6708; Fri, 1 Jul 2016 19:47:24 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: 'Julien Laganier' <julien.ietf@gmail.com>
References: <000901d14157$7052a680$50f7f380$@nict.go.jp> <CAE_dhjshGS19So1b_wuXLV1u7+jqw329LqT7t_OBzZQrGH0EsQ@mail.gmail.com>
In-Reply-To: <CAE_dhjshGS19So1b_wuXLV1u7+jqw329LqT7t_OBzZQrGH0EsQ@mail.gmail.com>
Date: Fri, 01 Jul 2016 19:47:24 +0900
Message-ID: <014b01d1d385$f3b39a00$db1ace00$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFfvRTvbwkjdx5jlulKrWATyyVqRgFkX6qJoNxtjqA=
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.7 at zenith2
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/OrdPt-X20gX4Ph50YbrcLSJyVEY>
Cc: draft-ietf-hip-rfc5203-bis.all@ietf.org, 'The IESG' <iesg@ietf.org>, hip-chairs@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-hip-rfc5203-bis-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 01 Jul 2016 10:47:33 -0000
Hello Julien, Thank you for your detailed explanation. I thought I have replied to your email before, but I haven't yet; I am sorry for that. I have also checked the updates you've made based on the gen-art review (and the related comments you've posted to the mailing list), and found no further comments. I think this draft is ready. Best regards, Take > -----Original Message----- > From: Julien Laganier [mailto:julien.ietf@gmail.com] > Sent: Monday, February 1, 2016 2:52 AM > To: Takeshi Takahashi > Cc: The IESG; hip-chairs@tools.ietf.org; secdir@ietf.org; > draft-ietf-hip-rfc5203-bis.all@ietf.org > Subject: Re: [secdir] Secdir review of draft-ietf-hip-rfc5203-bis-09 > > [resending with corrected typo in the recipient list. apologies for the > noise] > > Takahashi san, > > Thank you for reviewing the document, and my apologies for the belated reply. > Please find my answers to your comments/questions inlined > below: > > On Mon, Dec 28, 2015 at 2:06 AM, Takeshi Takahashi > <takeshi_takahashi@nict.go.jp> wrote: > > [...] > > > [overall feeling on this draft] > > > > ready, and good to proceed > > > > [overview] > > > > 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. > > > > [questions] > > > > 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? > > As the draft currently states, the suitability of certificates is likely > to be application-specific, i.e., dependent on the specific service for > which the requester seeks registration -- "How the suitability is determined > and how the certificates are obtained is out of scope for this document." > > For example there may not be a strict ordering of certificates w.r.t. > suitability to register, i.e., given two certificates A and B, there isn't > necessarily one that is more suitable than the other. > > For example, a requester for a service may have certificates issued by two > ISPs, such as a fixed wireline broadband ISP, and a mobile service provider. > These may have brokered roaming agreements with various other parties to > optimize topological closeness of the service registrar w.r.t. the > requester's current access network. If the requester always include both > certificates in its requests, this would avoid having to specify and > implement complex certificate selection logic on the requester. > > > 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? > > The Host Identity is the public component of a public-private key pair, and > since completion of the HIP exchange's mutual peer authentication requires > knowledge of the private component of the key pair, an attacker knowing the > public component would not be able to be granted any service registration > based on that knowledge. > > > 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 5203? > > The registration types are defined by the documents defining the service > for which registration is being sought, and recorded in the relevant IANA > registry. This document does not change the list of services currently being > registered with IANA: > > <http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hi > p-parameters-11> > > > 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? > > As the draft currently states: > > If the requester was not in the allowed list and the registrar > requires the requester to authenticate, the registrar MUST check > whether the packet also contains a CERT parameter. If the packet > does not contain a CERT parameter, the registrar MUST reject the > registrations requiring authentication with Failure Type 0 > (Registration requires additional credentials). > > "Registration requires additional credentials" is allocated in the relevant > IANA registry: > > <http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hi > p-parameters-13> > > Thanks again for the review. With best regards, > > --julien > > On Mon, Dec 28, 2015 at 2:06 AM, Takeshi Takahashi > <takeshi_takahashi@nict.go.jp> wrote: > > Hello, > > > > 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 directors. > > 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 > > > > [overview] > > > > 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. > > > > [questions] > > > > 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 5203? > > > > 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. > > Take > > > > > > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
- Re: [secdir] Secdir review of draft-ietf-hip-rfc5… Takeshi Takahashi
- [secdir] Secdir review of draft-ietf-hip-rfc5203-… Takeshi Takahashi
- [secdir] Secdir review of draft-ietf-hip-rfc5203-… Takeshi Takahashi
- Re: [secdir] Secdir review of draft-ietf-hip-rfc5… Julien Laganier
- Re: [secdir] Secdir review of draft-ietf-hip-rfc5… Julien Laganier