Re: [Hipsec] Unsticking HIP from 1st gear

Robert Moskowitz <rgm@htt-consult.com> Thu, 01 May 2014 22:30 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0201A09D4 for <hipsec@ietfa.amsl.com>; Thu, 1 May 2014 15:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level:
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm8eWnsZ2451 for <hipsec@ietfa.amsl.com>; Thu, 1 May 2014 15:30:01 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 00DB71A09FD for <hipsec@ietf.org>; Thu, 1 May 2014 15:30:01 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id D6E2062AC3 for <hipsec@ietf.org>; Thu, 1 May 2014 22:29:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3pnITfSSAcY for <hipsec@ietf.org>; Thu, 1 May 2014 18:29:46 -0400 (EDT)
Received: from lx120e.htt-consult.com (lx120e2.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 10FFE62AB8 for <hipsec@ietf.org>; Thu, 1 May 2014 18:29:45 -0400 (EDT)
Message-ID: <5362CAD9.1080609@htt-consult.com>
Date: Thu, 01 May 2014 18:29:45 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: hipsec@ietf.org
References: <53613E91.7010808@htt-consult.com>
In-Reply-To: <53613E91.7010808@htt-consult.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/XVP1ZogqPLP7YwliMhekEFhqAkU
Subject: Re: [Hipsec] Unsticking HIP from 1st gear
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 01 May 2014 22:30:03 -0000

On 04/30/2014 02:18 PM, Robert Moskowitz wrote:
> Automotive analogy because right now I have been dragged back to my 
> automotive history to work on the "Connected Car" security...
>
> I am working on multiple HIP projects. Real vendors with real products 
> for real customers. In some cases things are separate, but in some 
> there will be function overlap. I am working on HIP at multiple layers:
>
> MAC layer:
>
> 802.15.9 directly passing the HIP datagrams and keying the 802.15.4 
> security association.
> EAP-HIP for running over 802.1X and PANA. Yoshi has said he is willing 
> in writing the draft.
>
>
> Networking layer:
>
> Besides 5202-bis BEET mode for EAP, there are more calls for Tunnel mode.
>
> Transport layer:
>
> Alternative keying for things like DTLS-PSK or SRTP.
>
> Messaging/Session layer:
>
> Besides my work on SSE (Session Layer Security) there are a couple 
> other messaging environments that may create their own security 
> framework, but I am pushing SSE where I can.
>
> Authentication only:
>
> HIP for authentication within someother framework. This is still 
> rather vague and may end up elsewhere above.
>
> Anyway, HIP becomes an independed Key Management Protocol, needing a 
> well defined API (we did something like this at one point?) where 
> there can be many HIs for the different uses.

Miika and I had an email exchange and looking into RFC 6317, this is 
really the UNIX Sockets API enhanced for HIP. So this is the wrong API.

I am thinking about an API for HIP itself. If something wants keys via 
HIP, what does it provide and what does it get back.

I am interested in what others think about this. I will provide what I 
think about it.

>
> Though I can't give information on individual projects, "No Wine 
> Before its Time", there are some real projects in coding now and more 
> at various levels of discussion.
>
> For those of you that have HIP web pages that are two years out of 
> date, PLEASE get them current. It is embarrassing to be on a call with 
> a consortium (last friday) to have one person saying, "I just checked 
> out the site for the X code base and it has not been updated for two 
> years." Please fix this.
>
> Anyone with a bit of time ( :) ) over the next week to help me flesh 
> out HIP as a security service and review the API RFC, please contact 
> me. I still can't spill too many beans, but more will be leaking out 
> in the coming months....
>
> And I really hope we can get RFCs published by July. Meanwhile I also 
> have to finish up HIP DEX. Remaining stuff, I think, is only 
> explanatory. I believe Rene set me straight and we got it pretty much 
> nailed down in the latest draft. Though there is the question if 
> SLIMFIT should go into the DEX draft or be a separate document. 
> SLIMFIT with a bit more tweaking will fit into SMS packets without 
> need of the SMS header...
>
> Thank you for your time and efforts.
>
>
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>