Subject: Re: [Hipsec] Unsticking HIP from 1st gear

From: Robert Moskowitz <[email-masked]>
Date: Thu, 01 May 2014 18:29:45 -0400

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

---

From: Miika Komu <[email-masked]>
Date: Fri, 02 May 2014 17:42:23 +0300

Hi,

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

early draft of RFC6317 did have an API for configuring user-specific 
identities (i.e. asymmetric keys), but this feature was dropped later. 
Or are you referring to symmetric key APIs, like PFKEY:

http://www.ietf.org/rfc/rfc2367.txt

Please note that it requires administrative privileges in practice. Or 
perhaps you're thinking about "application identity protocol" as we 
drafted in the following thesis?

http://nordsecmob.aalto.fi/en/publications/theses_2012/gu-xin_thesis.pdf

Check out also:

https://www.usenix.org/legacy/event/sec05/tech/full_papers/yin/yin.pdf