Subject: [RAM] aside Re: HIP

From: RJ Atkinson <[email-masked]>
Date: Tue, 2 Jan 2007 17:15:22 -0500

I think HIP is really great research.  I am not quite
as enthusiastic about HIP as an operational solution.

	My main concern is that with HIP, when one's public key
is compromised (and, yes, that is always a WHEN, not an IF),
one always necessarily loses one's Identifier.  This seems
pretty undesirable to me.

	HIP-like solutions that don't have issues of that sort
are pretty different from any of the currently available HIP
specifications.  Yes, the HIP authors/editors left the door open
a crack, but AFAIK there isn't any proposal for how to make an  
Identifier
workable if the Identifier is not derived from one's public key.

	Also, for moderate threat environments, I think all the
HIP cryptography is overkill and computationally expensive.  I'd
prefer to have the option for a less computationally intense and
less comprehensive security mechanism for moderate threat environments.
(Something that merely prevented off-path attacks seems possible
to me and might be interesting to have as a deployment option.)

	Sigh.

Ran

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 3 Jan 2007 08:30:19 +0200

> as enthusiastic about HIP as an operational solution.

I don't think anyone has really worked out the operational details  
for HIP.  Partially the HIP folks have had too much to do to get the  
basic ideas to work, partially they have seen the SHIM6 folks doing  
good job that could be adopted to HIP, and partially it has just been  
a problem of few if any operational folks within the HIP community.

That said, a few things have been considered:

1. Firewall details.  E. Vehmersalo, Host Identity Protocol Enabled  
Firewall: A Prototype Implementation and Analysis, Master's thesis,  
September 2005.  http://infrahip.hiit.fi/papers/essi_dippa.pdf

2. Privacy.  L. Takkinen, Host Identity Protocol Privacy Management,  
Master's thesis, March 2006.  Also
Janne Lindqvist and Laura Takkinen, Privacy Management for Secure  
Mobility, ACM CCS Workshop on Privacy in
Electronic Society WPES 2006, Alexandria VA, USA, October 30, 2006.   
http://portal.acm.org/citation.cfm?doid=1179601.1179612

3. Legacy NATs and architected NATs.  See the various WG and RG drafts.	

> pretty undesirable to me.

I cannot but agree.

Currently, there are two known remedies:

1. Identity delegation with HIP allows you to leave your "primary  
identity" off-line, using only a temporary public key on-line.  This  
reduces the probability of the "primary identity" getting  
compromised.  BTW, the same approach seems to be sufficient for CA  
keys, but then there the keys are not used as identifiers.

2. There is a variant of HIP called lightweight HIP (LHIP), which  
doesn't use public keys.  Tobias Heer worked out the details as his  
thesis; unfortunately I wasn't able to find it online.

> less comprehensive security mechanism for moderate threat  

LHIP uses hash chains, IIRC.

--Pekka Nikander

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 3 Jan 2007 09:38:12 -0800

> -----Original Message-----
> From: RJ Atkinson [mailto:[email-masked]] 
> Sent: Tuesday, January 02, 2007 2:15 PM
> To: [email-masked]
> Subject: [RAM] aside Re: HIP
> 
> 

Ram,
Is your concern that HIP has not explicitly considered what to do when
an identifier is compromised, or that solutions that actually do
adequately treat situations for which an identifier is compromised are
necessarily much different from HIP design?  If the latter, can you
provide a pointer?

What do you view as the operational requirements on the security and
permanence of a network-level identifier?  Note that there have been
differing views on this; for instance, the identifiers could be
transient and anonymous, or semi-permanent and public, or even securing
the channel bindings for higher-layer protocol security.  Each of these
use cases has different operational implications for how seriously to
protect the identifier from compromise and undo the damage when
compromised.  To this point, HIP has deliberately avoided choosing one
of the above use cases, and may be why these solutions are
underdeveloped for HIP.

> to me and might be interesting to have as a deployment option.)

Pekka made reference to lightweight HIP using hash chains; although I
can't find the thesis, there is an expired internet draft with earlier
work:
http://tools.ietf.org/html/draft-nikander-multi6-hip-01 
which referenced the WIMP-F hash chain proposal for multi6:
http://tools.ietf.org/html/draft-ylitalo-multi6-wimp-01

Tom