Subject: [Hipsec] Registration certificate authentication for 5203bis

From: Ari Keranen <[email-masked]>
Date: Thu, 23 Sep 2010 12:22:39 +0300

Hi all,

In the HIP native NAT traversal draft we use certificates for 
authenticating the registration and I recently realized that the 
behavior we describe in the section 3.2 is probably pretty generic for 
this kind of use cases (just change "HIP relay" into something more 
generic). Therefore, it would make sense to rather have this 
functionality described in the registration document than in the NAT 
traversal document.

Any opinions on this? The text in section 3.2 of the HIP NAT traversal 
draft [1] could be used as a base for the new text.

Cheers,
Ari

[1]
http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-00#section-3.2

---

From: Miika Komu <[email-masked]>
Date: Thu, 23 Sep 2010 12:50:16 +0300

Hi,

this seems pretty generic (excluding the relay specific sentence in the 
beginning). I would be in favor of this small change because it seems to 
have little impact on RFC5203. The only dependency seems to be the cert 
draft but it should be in WGLC this month.

On 09/23/2010 12:22 PM, Ari Keranen wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: Samu Varjonen <[email-masked]>
Date: Thu, 23 Sep 2010 13:57:37 +0300

On 09/23/2010 12:50 PM, Miika Komu wrote:
> have little impact on RFC5203.

+1

The only dependency seems to be the cert
> draft but it should be in WGLC this month.

Just uploaded the updated version of the cert draft for this purpose.

---

From: Tobias Heer <[email-masked]>
Date: Thu, 23 Sep 2010 15:28:50 +0200

Hi. 

Am 23.09.2010 um 11:22 schrieb Ari Keranen:

> Hi all,
> 
> In the HIP native NAT traversal draft we use certificates for authenticating the registration and I recently realized that the behavior we describe in the section 3.2 is probably pretty generic for this kind of use cases (just change "HIP relay" into something more generic). Therefore, it would make sense to rather have this functionality described in the registration document than in the NAT traversal document.
> 
> Any opinions on this? The text in section 3.2 of the HIP NAT traversal draft [1] could be used as a base for the new text.
> 

I agree. The relay document seems to be the proper place to discuss this.

Tobias

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 27 Sep 2010 12:55:29 -0700

Hi,

One issue with this is that the HIP certificate spec is Experimental, and the revised registration is going to be Standards Track. If we reference the certificate spec from the registration spec we'll get a downref which will have to be justified at IESG. Not sure we have a good story for this...

Now looking at [1] below I found this:

   When a host wants to register with a HIP data relay, it SHOULD check
   if it has a suitable certificate for authenticating with the relay.
   How the suitability is determined and how the certificates are
   obtained is out of scope for this document.

This seems to indicate that the use of certificates with HIP, in addition to being experimental, is also underspecified ("out of scope" wording.)

I am thinking it might be more appropriate to specify a behavior for a host to accept or not a certificate as suitable in the HIP Certificates specifications [2] ?

--julien

[1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-00#section-3.2
[2] http://tools.ietf.org/html/draft-ietf-hip-cert-03

Ari Keranen wrote:
> [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-00#section-3.2

---

From: Ari Keranen <[email-masked]>
Date: Wed, 29 Sep 2010 17:39:36 +0300

Hi Julien,

On 09/27/2010 10:55 PM, Laganier, Julien wrote:
> One issue with this is that the HIP certificate spec is Experimental,
> and the revised registration is going to be Standards Track. If we
> reference the certificate spec from the registration spec we'll get a
> downref which will have to be justified at IESG. Not sure we have a
> good story for this...

Good point. Are we planning to bis CERT too? I guess we need to since 
also 5201bis will probably reference CERT, now that it's finally specified.

> This seems to indicate that the use of certificates with HIP, in
> addition to being experimental, is also underspecified ("out of
> scope" wording.)
>
> I am thinking it might be more appropriate to specify a behavior for
> a host to accept or not a certificate as suitable in the HIP
> Certificates specifications [2] ?

Actually, I already discussed this with the authors of the CERT draft 
and we came into conclusion that this behavior is often really context 
specific and thus better defined within the context (i.e., for 
registration, in the registration spec). That said, some generic text 
could be a good idea and some behavior of what to do if certificate is 
not valid is already specified in the -04 version of the CERT draft [3].

Cheers,
Ari

[3] http://tools.ietf.org/html/draft-ietf-hip-cert-04#section-6