Re: [Hipsec] Status of WG items

Ari Keranen <ari.keranen@nomadiclab.com> Tue, 31 July 2012 16:13 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 7A9FB21F86C9 for <hipsec@ietfa.amsl.com>; Tue, 31 Jul 2012 09:13:46 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os3Y0n-1lSd2 for <hipsec@ietfa.amsl.com>; Tue, 31 Jul 2012 09:13:46 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id C9DED21F86B0 for <hipsec@ietf.org>; Tue, 31 Jul 2012 09:13:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 9D4904E6E9; Tue, 31 Jul 2012 19:13:43 +0300 (EEST)
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 y7uUAeQgWDpb; Tue, 31 Jul 2012 19:13:43 +0300 (EEST)
Received: from dhcp-6227.meeting.ietf.org (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 2719B4E6E6; Tue, 31 Jul 2012 19:13:41 +0300 (EEST)
Message-ID: <50180434.8010907@nomadiclab.com>
Date: Tue, 31 Jul 2012 09:13:40 -0700
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Robert Moskowitz <rgm@htt-consult.com>
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> <5012E621.908@htt-consult.com>
In-Reply-To: <5012E621.908@htt-consult.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Julien Laganier <julien.ietf@gmail.com>, Julien Laganier <julien.laganier@gmail.com>, 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: Tue, 31 Jul 2012 16:13:46 -0000

On 7/27/12 12:04 PM, Robert Moskowitz wrote:
>
> On 07/27/2012 12:22 PM, Ari Keranen 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?
>
> These are all reasonable. I am more and more looking at HIT
> authentication services, but I know the value of certificates in
> processes like this, though I keep taking a look at things like ECQV
> certs as an alternative to X.509 certs...

Thanks Bob. Frankly, I'm not a big fan of X.509 certs either, so 
something else would work for me too. Anyway, something more than "just 
knowing HIs" would be useful.


Cheers,
Ari