Re: [Hipsec] Fwd: Status of WG items

[Gonzalo Camarillo <[e-mail]>]

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
> <[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
>>>
>>
> 
>