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