[Hipsec-rg] discussion of draft-lee-hip-object-01

thomas.r.henderson at boeing.com (Henderson, Thomas R) Wed, 10 December 2008 21:25 UTC

From: "thomas.r.henderson at boeing.com"
Date: Wed, 10 Dec 2008 13:25:20 -0800
Subject: [Hipsec-rg] discussion of draft-lee-hip-object-01
In-Reply-To: <002701c959d0$ba69df20$2f3d9d60$@gov>
References: <77F357662F8BFA4CA7074B0410171B6D07B0BB86@XCH-NW-5V1.nw.nos.boeing.com> <493D5698.9090307@hiit.fi> <002701c959d0$ba69df20$2f3d9d60$@gov>
Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0BBB0@XCH-NW-5V1.nw.nos.boeing.com>

 

> -----Original Message-----
> From: Gyu Myoung Lee [mailto:gmlee at nist.gov] 
> Sent: Monday, December 08, 2008 11:36 PM
> To: miika.komu at hiit.fi; hipsec-rg at listserv.cybertrust.com
> Cc: jkchoi at icu.ac.kr; skjo at etri.re.kr; gurtov at hiit.fi; 
> Henderson, Thomas R
> Subject: RE: [Hipsec-rg] discussion of draft-lee-hip-object-01
> 
> 
> Dear All,
> 
> As I already presented at Minneapolis meeting, there are 
> recent trends in
> order to specify the object-to-object communications in relevant
> standardization bodies for future challenging work. Regarding 
> this, although
> we have alternative solutions, I believe that to extend the 
> current HIP for
> supporting all of objects is right direction.
> 
> Currently the basic concept and several considerations, etc 
> are already
> specified in this document. However, for more technical 
> details, I expect
> many experts to actively participate in the drafting work 
> after adopting as
> one of RG items.

I have a question about this draft, for the authors.

If I understand correctly, one way to restate the problem is that you
are interested in extending HIP to allow for objects other than host
TCP/IP stacks to be named; that you really would like HIP to be extended
such that "Host" could be extended to include "Object" or as suggested
at the RG meeting, "Endpoint".  Please clarify if this is an incorrect
perspective on what you are requesting.

However (and I think Bob and Andrew made this point at the RG meeting),
it seems that rather than replace the host identifier with an object
identifier (which may or may not have cryptographic properties), one
could perhaps instead ensure that the thing put into the Host Identity
of the HOST_ID parameter was still a public key, and that the Domain
Identifier could be changed.

That is, your draft proposes the following:

   o Object_ID (newly defined from HOST_ID of HIP) 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |             Type              |             Length            | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |          OI Length            |DI-type|      DI Length        | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                        Object Identity                        / 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    /                               |         Domain Identifier     / 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    /                                               |    Padding    | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


However, an alternative would be to keep the existing HOST_ID:

5.2.8.  HOST_ID

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          HI Length            |DI-type|      DI Length        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Host Identity                         /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                               |         Domain Identifier     /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                               |    Padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and add the following new DI-type:

   The following DI-types have been defined:

          Type                    Value
          none included           0
          FQDN                    1
          NAI                     2
+         Object ID               3

and then specify a new Domain Identifier format for the Object ID.

Would that accomplish the same goal, and if not, why not?  Because if it
were to accomplish your goal, then HIP (security properties) would not
really need to be changed as drastically.

Also, there is another option to consider:  X.509 or SPKI certificates,
which are going to be carried in HIP:
http://www.ietf.org/internet-drafts/draft-ietf-hip-cert-00.txt

Would that also be of use to your use case?

Tom