[core] HIP identities and puzzle (was: Fwd: Wed 29, 1500 UTC (Fwd: Meeting invitation: CORE WG))

[Tobias Heer <[e-mail]>]

Hi Rene, 

From discussions with Robert in the HIP RG and from his presentations I take that DEX/Diet HIP is an initial offer from Bob in which he tries to cut down the computational cost of the crypto-primitives and implementation cost of HIP as low as possible while still maintaining its key features. From your mail and some offline discussions I take that this cut might have been too low for some people and that the use of non-cryptographic names bound via certificates might be an enabler for some scenarios. In this regard, the list of security and operational requirements in the end of your e-mail might help Bob and other authors a lot because they can test their work against such list.

I'll try to address some of your questions in line.


Am 01.10.2010 um 18:16 schrieb Rene Struik:

> Hi Zhen:
> 

[...]
> 
> From what I do understand, though, identities are a function of the long-term public key (witness also Section 3.2 of draft-ietf-hip-rfc5201-bis-02, which forementioned HIP-DEX draft presumes familiarity with). If so, pragmatically, identities are public keys and, thereby, would change depending on key lifecycle considerations. In my mind, this seems a no-go to get mass-scale deployment from the ground.
> 
Your concerns got me thinking and I came up with something that might solve your problem (or rather the problem of HIP) here. I'll briefly try to explain the idea.

Right now we are making the concept of the Host ID (HI) and the Host Identity Tag (HIT) (the IPv6-like identity that is visible to most applications) more flexible in HIPv2[1]. This change, which originally aimed at providing improved crypto agility, can be used to create a kind of non cryptographic HITs that are bound to HIs via certificates instead of using simple hashing. Such HIs/HITs could be used in scenarios which require more sophisticated identity management while traditional HIs/HITs could be used in scenarios that can live with simpler approaches. 

Let me illustrate this with a little bit of ascii art. I'll use the following abbreviations and notations to keep the lines short:
I enumerated the mappings in HIP/DEX with m1..m3. The arrows <--mx:mapping_name-- signify the mappings. PK is a public key for a signature algorithm, PKDH is the public key for an ephemeral Diffie Hellman, PKSDH is the public key for a static Diffie Hellman exchange. SK is a symmetric session key. 

Right now we have the following mappings between HIs and the security associations that HIP and DEX set up:

For HIP we have:
HIT <--m1:Hash-- PK(HI) <--m2:Signature-- PKDH <--m3:DH_exchange--SK

AFAIK for DEX it looks like this:
HIT <--m1:truncate-- PKSDH <--m2:DH_exchange--SK

These two or three mappings in HIP/DEX make sure that the session key is related to the HIT.
If one wanted the HIT to be independent of the cryptographic keys, it would be simple to define a new kind of HIT/HI for which the mapping would look like this:

HIT <--m1:hash/truncate-- String <--m2:certificate-- PKSDH <--m3:DH_exchange-- SK

This means that the HIT is generated from an arbitrary string (e.g., node ID, vendor ID, node function or a service name - anything). This string is hashed to get it into IPv6 like form so that it can be used just as the HIT.
The actual Host ID would be a certificate (issued by a trusted third party) that binds this string to a static DH public key. The process of generating a HI could be like this. 1. Pick node string (e.g., "Node222:Temperature sensor"), 2. generate static DH public key, 3. generate certificate covering string and DH public key, 4. give DH public/private key pair and certificate to the node.
This would mean that (provided that there is a trusted third party) one could use descriptive strings in HIP in the same way that cryptographic names are used. The way that applications deal with HITs and the actual HIP handshake would stay almost the same. The only difference is that the peers use the third-party certificates to verify mapping m2.

This is just a first sketch without proper specification. However, adding such certificate-based host identities to HIP shouldn't be hard and won't break anything. René Hummen agreed to provide a draft that fleshes out this approach if CORE or HIPRG/WG deem it interesting.

> BTW (not relevant to authentication topic) - It is not immediately clear whether the "puzzle" presented from responder to initiator (Puzzle is to compute J so that x:=CMAC_I (  Id_A || Id_B || J) has a pre-fixed pattern on K bit positions) does not allow for "shortcuts", thus allowing its solution with expenditure of far less than 2^K trial-and-error computing rounds. Can't one do a meet-in-the-middle type of attack here? Anyway, not directly relevant to the authentication question at hand (although perhaps adding to confusion).

I see your point here. If cmac is particularly susceptive to a meet-on-the-middle attack one could slightly modify the puzzle so that instead of requiring a certain length of 0 bits in the beginning of the solution, a match with a random/pseudorandom string is required. The pseudorandom string should not be known to the Initiator before the connection attempt and could be connection specific or could cycle. This would make it hard to precompute the second step of the meet-in-the-middle attack because this step will be different for each puzzle.

> To aid clarity and succinct discussions, it would help to have a clear description of desired security services to be offered by an authenticated key agreement scheme and see whether a candidate scheme (such as, who knows, HIP) satisfies these. If you could provide a succinct description of the HIP protocol itself, so that this is easy to understand, and could provide what properties it has, that would be of great help!
> 
> In my mind, properties of suitable authenticated key agreement schemes should include (a) key establishment; (b) implicit key authentication; (c) key confirmation; (d) mutual entity authentication; (e) forward secrecy; (f) {perhaps} some more esoteric properties (key compromise impersonation resilience, etc.).
> 
Is this list valid for all targeted use cases? If yes, it is a very handy list to check against. However, (e) forward secrecy seems to rule a number of "cheaper" cryptographic approaches (e.g., pre-shared keys) and might not be relevant to all use cases (especially small setups). However, I am not absolutely firm with the envisaged scenarios in CORE.

> Moreover, the "name space" (device identifiers) and the "cryptographic space" (public keys, etc.) should be independent, so that this would allow trust lifecycle management to be reduced to proper management of device identifiers (i.e., *no* entanglement of concepts from different disciplines).
 
Does the "*no* entanglement of concepts from different disciplines" also mean that a concept like the id/loc split should be used to avoid entanglement of routing and naming?

BR,

Tobias



[1] draft-ietf-hip-rfc5201-bis-02: http://www.ietf.org/id/draft-ietf-hip-rfc5201-bis-02.txt

> On 01/10/2010 10:59 AM, Zhen Cao wrote:
>> On Fri, Oct 1, 2010 at 9:57 PM, Rene Struik<[e-mail]>  wrote:
>>> Hi Zhen:
>>> 
>>> To my knowledge (cf. also Slides 48-51 inter alia of IETF-78 6lowpan slide
>>> deck), the HIP-DEX protocol only provides evidence that the communicating
>>> parties involved with the key agreement scheme had access to the long-term
>>> private key (i.e., key possession), not of their identity. These properties
>>> are essentially those offered by the ephemeral Diffie-Hellman (DH) key
>>> agreement scheme (which does not provide for authentication of either party
>>> involved with the protocol); hence, my reference hereto.
>> I was based on draft-moskowitz-hip-rg-dex-02, section 4.1.  On page 8,
>> the HIP diet exchange I2 and R2 include a computed MAC, I think it is
>> used for authentication of either party.
>> 
>> The full capability HIP is able to do the authenticated key exchange,
>> your concern is that current Diet-HIP cannot do that? If so, we can
>> input this as a requirement for Diet-HIP while it is not so closed to
>> an RFC.
>> 
>> Thanks,
>> Zhen
>> 
>>> Please note that those slides refer to NIST SP 800-56a (Para 6.3.2, Para
>>> 6.3.3), which describes C(0,2), i.e., DH using static keys, where key
>>> derivation includes use of nonce provided by the initiating party. As such,
>>> this does not include the use of signatures. As final notes: (a) the C(0,2)
>>> scheme assumes that public keys are tied to identities (cf. Para 6.3.3, l.
>>> 1); (b) the scheme does not provide forward secrecy (i.e., compromise of a
>>> device may compromise past secrets established with that device [in my mind,
>>> an undesirable property for internet of things type devices, which cannot be
>>> assumed to have physical protection and may be placed out in the open (e.g.,
>>> screwed on a garage or street lamp post)]).
>> I will check with the NIST document and come back soon.
>> 
>>> Best regards, Rene
>>> 
>>> 
>>> On 01/10/2010 9:07 AM, Zhen Cao wrote:
>>>> Excuse me to jump into the discussion. I am also interested in
>>>> HIP/Diet-HIP protocol.
>>>> 
>>>> In my mind, HIP offers authenticated key exchange via the use of
>>>> signatures, i.e., the DH exchange is signed and thus authenticated.
>>>> After the exchange, IPSEC ESP is established and data authentication
>>>> is achieved via the IPSEC SA.
>>>> 
>>>> Thanks,
>>>> Zhen
>>>> 
>>>> On Thu, Sep 30, 2010 at 6:19 AM, Rene Struik<[e-mail]>
>>>> wrote:
>>>>> Hi Carsten:
>>>>> 
>>>>> Thanks for the minutes. I just had a quick look and somehow seemed to
>>>>> have
>>>>> missed during the conf call your reference to the HIP protocol. Could you
>>>>> elaborate a little bit more? To my knowledge, HIP essentially does
>>>>> ephemeral
>>>>> Diffie-Hellman key agreement, thus not offering authenticated key
>>>>> agreement.
>>>>> In my mind, authenticated key agreement is essential to trigger data
>>>>> authentication tied to a unique identifier and allow trust lifecycle
>>>>> management to be reduced to management of device identities (via use of
>>>>> certificates). See also the brief summary below.
>>>>> 
>>>>> Perhaps, we should discuss this somewhat more early next week.
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> Rene
>>>>> 
>>>>> [summary of old proposal of mine on trust lifecycle management that could
>>>>> be
>>>>> used with bootstrapping document]
>>>>> §1 Proposal summary
>>>>> 
>>>>> The proposal encompasses an intuitive, yet secure approach to
>>>>> provisioning
>>>>> and configuration of sensor networks. The approach hides security details
>>>>> from the user, thus allowing ease of device and network setup and
>>>>> flexibility of trust lifecycle management, while doing away with security
>>>>> hassles that have plagued more conventional approaches.
>>>>> 
>>>>> The proposal uses public-key cryptography, a security technology that
>>>>> allows reduction of trust lifecycle management to the management of
>>>>> trusted
>>>>> device identities (via so-called certificates), and security policy
>>>>> enforcement techniques based on lifecycle management of device roles.
>>>>> 
>>>>> From a user’s perspective, this results in a system where trusted
>>>>> lifecycle
>>>>> management appears to be the same as that of an unsecured network: it
>>>>> simply
>>>>> comes down to proper identification of devices (e.g., reading off a label
>>>>> of
>>>>> a physical module) and proper management of device roles (e.g., adding
>>>>> these
>>>>> to, resp. removing these from a white list, e.g., via a workstation GUI).
>>>>> No
>>>>> secret information is disclosed at any lifecycle stage of a device or a
>>>>> system, nor needs to be, since management relies completely on handling
>>>>> of
>>>>> public information. This greatly reduces the complexity of lifecycle
>>>>> management and, thereby, training requirements for operational personnel.
>>>>> Moreover, it virtually removes trust dependencies between different
>>>>> entities
>>>>> involved in the value chain, whether OEM, vendor, system integrator,
>>>>> installer, or user. Lastly, the approach has the benefit of allowing
>>>>> enforcement of standards compliance (by only issuing a certificate to
>>>>> devices from vendors that passed conformance testing).
>>>>> 
>>>>> 
>>>>> 
>>>>> On 29/09/2010 5:36 PM, Carsten Bormann wrote:
>>>>> 
>>>>> On Sep 29, 2010, at 15:33, Carsten Bormann wrote:
>>>>> 
>>>>>     http://6lowapp.net/2010-09-29/
>>>>> 
>>>>> ... and the minutes are now also up there.
>>>>> Please tell me if I have misrepresented anyone.
>>>>> 
>>>>> At 90 minutes, this was a short and sweet meeting.  Thanks to everyone
>>>>> who
>>>>> participated, and in particular to Markus Becker who at very short notice
>>>>> volunteered to take notes (all errors in the massaged version are of
>>>>> course
>>>>> mine).
>>>>> 
>>>>> Gruesse, Carsten
>>>>> 
>>>>> _______________________________________________
>>>>> core mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/core
>>>>> 
>>>>> 
>>>>> --
>>>>> email: [e-mail]
>>>>> Skype: rstruik
>>>>> cell: [phone]
>>>>> USA Google voice: [phone]
>>>>> 
>>>>> _______________________________________________
>>>>> core mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/core
>>>>> 
>>>>> 
>>> 
>>> --
>>> email: [e-mail]
>>> Skype: rstruik
>>> cell: [phone]
>>> USA Google voice: [phone]
>>> 
>>> 
> 
> 
> -- 
> email: [e-mail]
> Skype: rstruik
> cell: [phone]
> USA Google voice: [phone]
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core




-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi