Re: [Hipsec] Unsticking HIP from 1st gear

[Miika Komu <[e-mail]>]

Hi,

On 05/02/2014 01:29 AM, Robert Moskowitz wrote:
>
> 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.

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