Subject: Re: [Hipsec] Status of WG items

From: Ari Keranen <[email-masked]>
Date: Fri, 14 Dec 2012 14:43:01 +0200

So, what's blocking the progress on this is the lack of STD track CERT 
draft.

Samu and Tobi, would you have cycles to move your experimental track 
CERT RFC into STD track draft? I guess not much (or anything except the 
category?) need to be changed from the current RFC doc.

Cheers,
Ari

On 9/21/12 11:11 AM, Gonzalo Camarillo wrote:
> Hi Julien,
>
> my take on this is that we need to produce a standards-track document
> specifying exactly that. This is what our charter says about it:
>
> https://datatracker.ietf.org/wg/hip/charter/
>
>> o Specify in a standards track RFC how to carry certificates in the
>> base exchange. This was removed from the base HIP spec so that the
>> mechanism is specified in a stand-alone spec.
>
> Cheers,
>
> Gonzalo
>
> On 21/09/2012 2:49 AM, Julien Laganier wrote:
>> On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen <[email-masked]> wrote:
>>> Hi Julien,
>>>
>>>
>>> On 7/6/12 3:37 AM, Julien Laganier wrote:
>>>>
>>>> - 5203bis (registration) can IMHO be republished as is as I haven't
>>>> seen any issue with the original version. If people agree I could
>>>> republish it and we could WGLC it...
>>>
>>>
>>> I posted some comments about 5203bis earlier this year but back then there
>>> was no discussion regarding them. So, here goes again.
>>>
>>> Some of these have been discussed also earlier on this list (these relate to
>>> requirements discovered with the native NAT traversal draft [1]), but I'll
>>> have them all here for easier reference.
>>>
>>> Currently, the registrar has no way of indicating that it would otherwise
>>> accept the registration, but it's currently running low on resources. For
>>> this purpose, a failure type "Insufficient resources" could be added to the
>>> "registration failure types".
>>>
>>> Registration using authentication with certificates could be part of the
>>> registration RFC. Currently, only authentication with HI is defined, but
>>> knowing all HIs beforehand is not practical in many cases.
>>>
>>> Text in section 3.2. of [1] could be used as a basis for this (just replace
>>> "HIP' data relay" with "registrar"). Also, if this authentication mode is
>>> added to the draft, failure type "Invalid certificate" should be added for
>>> the failure case.
>>>
>>> Should we have these in the registration draft?
>>>
>>> [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal
>>
>> I was going to shamelessly copy/paste section 3.2 of [1] in the
>> registration draft but I noticed that [1] actually has a normative
>> dependency on RFC 6253 "Host Identity Protocol Certificates" which is
>> Experimental. Thus adding the support for certificates to a standard
>> track HIP registration would cause a so-called downref which could be
>> problematic...
>>
>> Gonzalo - what is your take on this?
>>
>> --julien
>>
>

---

From: Ari Keranen <[email-masked]>
Date: Fri, 14 Dec 2012 15:14:50 +0200

Or we can do this.

However, I would not be too concerned for the CERT draft blocking the 
reg draft given that the CERT draft should not require much (any?) 
changes for STD track. Of course that would need someone driving that 
work too.

If there's not enough interest for that work (I think it's important but 
don't have the cycles to do it myself), it makes sense to go forward as 
proposed below.

Cheers,
Ari

On 10/18/12 4:15 PM, Miika Komu wrote:
> Hi Julien,
>
> your suggestion sounds fine.
>
> On 09/25/2012 10:26 AM, Gonzalo Camarillo wrote:
>> Hi,
>>
>> if we have the appropriate hooks in the main specs, we could do as you
>> suggest. I would be interested in hearing more opinions, though.
>>
>> Cheers,
>>
>> Gonzalo
>>
>> On 24/09/2012 5:48 PM, Julien Laganier wrote:
>>> Hi Gonzalo, all,
>>>
>>> So if we include in the registration a dependency towards the standard
>>> tracks HIP certificates draft (that doesn't exist yet) we would be
>>> tying the two together such that the registration can't be published
>>> before the HIP certificate RFC is.
>>>
>>> An alternative would be to move ahead with the current registration
>>> draft without specific dependency on HIP certificates but leaving the
>>> door open for these to be used once they are defined in standard
>>> track; the current draft and RFC already have hooks for authentication
>>> means beyond HIT authentication:
>>>
>>>
>>>                     In particular,
>>>     REG_FAILED with a failure type of zero indicates the service(s)
>>>     type(s) that require further credentials for registration.
>>>
>>>     If the registrar requires further authorization and the requester
>>> has
>>>     additional credentials available, the requester SHOULD try to
>>>     register again with the service after the HIP association has been
>>>     established.  The precise means of establishing and verifying
>>>     credentials are beyond the scope of this document and are
>>> expected to
>>>     be defined in other documents.
>>>
>>> Would that be an appropriate way forward?
>>>
>>> --julien
>>>
>>> On Fri, Sep 21, 2012 at 1:11 AM, Gonzalo Camarillo
>>> <[email-masked]> wrote:
>>>> Hi Julien,
>>>>
>> _______________________________________________
>> Hipsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/hipsec
>>
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 14 Dec 2012 23:40:58 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ari Keranen
> Sent: Friday, December 14, 2012 5:15 AM
> To: [email-masked]
> Subject: Re: [Hipsec] Fwd: Status of WG items
> 
> Or we can do this.
> 
> If there's not enough interest for that work (I think it's important
> but don't have the cycles to do it myself), it makes sense to go
> forward as proposed below.

I agree with the above.  I would support carrying them forward as is and trying to publish together, but if the authors prefer to decouple, I would be fine with that approach.

- Tom

---

From: Miika Komu <[email-masked]>
Date: Sat, 15 Dec 2012 09:51:07 +0200

Hi,

> I agree with the above.  I would support carrying them forward as is and trying to publish together, but if the authors prefer to decouple, I would be fine with that approach.

I would also suggest pushing CERT draft to the standards track if the 
authors can contribute some cycles.

---

From: Samu Varjonen <[email-masked]>
Date: Sat, 15 Dec 2012 12:40:16 +0200

15.12.2012 9:51, Miika Komu kirjoitti:
>> I agree with the above.  I would support carrying them forward as is
>> and trying to publish together, but if the authors prefer to decouple,
>> I would be fine with that approach.
>

I can contribute some cycles.

BR,
Samu

---

From: Ari Keranen <[email-masked]>
Date: Mon, 17 Dec 2012 10:41:14 +0200

> I can contribute some cycles.

Excellent, thanks Samu!

Julien, if we can get CERT moving, do you agree that this way forward 
makes sense?

Cheers,
Ari