[Hipsec] Fwd: Status of WG items

[Julien Laganier <[e-mail]>]

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