Re: [Hipsec] Status of WG items

[Gonzalo Camarillo <[e-mail]>]

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 <[e-mail]> 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
>