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 protected]> 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 protected]> >>> 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 [email protected] https://www.ietf.org/mailman/listinfo/hipsec
