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

[Julien Laganier <[e-mail]>]

[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
<[e-mail]> 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#hip-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#hip-parameters-13>

Thanks again for the review. With best regards,

--julien

On Mon, Dec 28, 2015 at 2:06 AM, Takeshi Takahashi
<[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview