Telechat Review of draft-ietf-hip-rfc5203-bis-10
review-ietf-hip-rfc5203-bis-10-secdir-telechat-takahashi-2016-07-07-00

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

 at gmail.com]
> Sent: Monday, February 1, 2016 2:52 AM
> To: Takeshi Takahashi
> Cc: The IESG; hip-chairs at tools.ietf.org; secdir at ietf.org;
> draft-ietf-hip-rfc5203-bis.all at 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 at 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 at 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 at ietf.org
> >

https://www.ietf.org/mailman/listinfo/secdir

> > wiki:

http://tools.ietf.org/area/sec/trac/wiki/SecDirReview