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, 1 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