[Hipsec-rg] reverse DNS lookups of HITs

[thomas.r.henderson at boeing.com (Henderson, Thomas R)]

 

> -----Original Message-----
> From: JiangSheng 66104 [mailto:shengjiang at huawei.com] 
> Sent: Thursday, January 15, 2009 3:05 AM
> To: Henderson, Thomas R
> Cc: oleg.ponomarev at hiit.fi; 
> hipsec-rg at listserv.cybertrust.com; brian at cs.auckland.ac.nz; 
> shengjiang at huawei.com
> Subject: Re: RE: [Hipsec-rg] reverse DNS lookups of HITs
> 
> > Regarding your proposal:
> > 
> >   For index and resolution purposes, HITs are aggregatable with 
> >   management domain tags of arbitrary bit-length, similar to IPv4 
> >   addresses under Classless Inter-Domain Routing [RFC4632]. 
> > ...
> >   The most important security property of HIT is that it is self-
> >   certifying (i.e., given a HIT, it is computationally hard to 
> > find a 
> >   Host Identity key that matches the HIT). Although this document 
> >   limits the hash output to be 94-bit long, it does not affect the 
> > self
> >   certifying security property. 
> > 
> > It seems to me that this self-certifying property is lost if one
> > prepends an unsecured management domain tag.  There is nothing 
> > stoppinga malicious node from using management domain tags of its 
> > choosing to
> > evade ACLs that are based on management domain tags.  
> 
> You are right here.
> 
> However, as it is a ongoing proposal, we are planning to 
> improve this in the future version, by including management 
> domain tag as a part of input for hash algorthim. This will 
> bind management domain tag with other security properties, 
> like what CGA does. Hence, the ACL that are based on 
> managment domain tags can verify a HHIT (for example, using 
> trust anchor, etc.) without recording every HIT in its list.
> 

I'm still not convinced about basing ACLs on management domain tags
directly.  You still need some kind of authorization from the trust
anchor to use the management tag.  This is likely done with
certificates.  But in that case, you are free to use whatever name in
the certificate as the name in the ACL.

For example, let's say you are a middlebox that wants to enforce that
only HITs authorized by example.com can access a service.  If the HIP
base exchange contains a certificate from a suitable trust anchor, one
can make the ACLs based on, for example, DNS names with the suffix
"example.com".  This name can be in the certificate.  And then, in
policy-enforcement filter, once a session is authenticated, a bypass for
the SPIs and HITs involved can be put into the middlebox.  If a
management domain tag is used instead, I'm not sure you can short cut
any of the above steps to authenticate the use of the tag.  So, it seems
like the proposed HIP Certificate extensions provide a more flexible
name space for ACLs.

Rather, I see value in having a so-called Type 2 HIT (see old HIP drafts
for this terminology) primarily for the use case that Oleg originally
raised, to facilitate reverse lookups, but with some scaling and
allowance for multiple name service providers to exist.

For instance, if we were able to get a reasonably sized prefix allocated
from IPv6 space (such as what ULAs received), we could use ~20 to 24
bits for this prefix and ~96 to 100 bits for hash.  The 24 bits could
probably be divided into something like 8 bits private use and 16 bits
public use, and "HIP name service providers" could register for a value
in the public bits.  

Tom