Re: [Hipsec] Fwd: Status of WG items

[Ari Keranen <[e-mail]>]

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
>>> <[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
>>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Hipsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hipsec
>>
>
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec