Re: [Hipsec] Status of WG items

Ari Keranen <ari.keranen@nomadiclab.com> Fri, 14 December 2012 12:43 UTC

Return-Path: <ari.keranen@nomadiclab.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE37A21F841F for <hipsec@ietfa.amsl.com>; Fri, 14 Dec 2012 04:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywD7o1bPgjfa for <hipsec@ietfa.amsl.com>; Fri, 14 Dec 2012 04:43:06 -0800 (PST)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D35C21F8231 for <hipsec@ietf.org>; Fri, 14 Dec 2012 04:43:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id E5F184E6EF; Fri, 14 Dec 2012 14:43:03 +0200 (EET)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz9d84W00wiW; Fri, 14 Dec 2012 14:43:02 +0200 (EET)
Received: from tri62.nomadiclab.com (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 7D6404E6EC; Fri, 14 Dec 2012 14:43:02 +0200 (EET)
Message-ID: <50CB1ED5.2040103@nomadiclab.com>
Date: Fri, 14 Dec 2012 14:43:01 +0200
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Tobias Heer <heer@cs.rwth-aachen.de>, Samu Varjonen <samu.varjonen@helsinki.fi>
References: <4FE96F9F.3090800@ericsson.com> <758141CC3D829043A8C3164DD3D593EA1BD324E110@XCH-NW-16V.nw.nos.boeing.com> <4FEA1876.900@cs.rwth-aachen.de> <CAE_dhjveQ6WVVE3BVKk2txfBxNhfWvjbz+QVU2P919dNZ1WO4A@mail.gmail.com> <5012C05B.6080203@nomadiclab.com> <CAE_dhjufW+ic-VaBtqs787jK=xxy_XxnegpgGEtmpjZHsmJ4nA@mail.gmail.com> <505C213F.6050701@ericsson.com>
In-Reply-To: <505C213F.6050701@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Julien Laganier <julien.ietf@gmail.com>, "hipsec@ietf.org" <hipsec@ietf.org>
Subject: Re: [Hipsec] Status of WG items
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Dec 2012 12:43:08 -0000

So, what's blocking the progress on this is the lack of STD track CERT 
draft.

Samu and Tobi, would you have cycles to move your experimental track 
CERT RFC into STD track draft? I guess not much (or anything except the 
category?) need to be changed from the current RFC doc.


Cheers,
Ari


On 9/21/12 11:11 AM, Gonzalo Camarillo 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 <ari.keranen@nomadiclab.com> 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
>>
>