Subject: [Hipsec-rg] discussion of draft-lee-hip-object-01
From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Wed, 17 Dec 2008 13:40:55 -0800

Gyu, some responses inline below. 

> -----Original Message-----
> From: Gyu Myoung Lee [mailto:gmlee at icu.ac.kr] 
> Sent: Monday, December 15, 2008 4:12 AM
> To: Henderson, Thomas R
> Cc: skjo at etri.re.kr; jkchoi at icu.ac.kr; 
> hipsec-rg at listserv.cybertrust.com
> Subject: RE: [Hipsec-rg] discussion of draft-lee-hip-object-01
> 
> 
> Dear All
> 
> See detailed answers on questions.
> 
> - who (which software processes) is communicating with whom?  
> A software
> process on an RFID reader talking with a centralized controller or
> inventory manager, for instance?
> 
> HIP Initiator can be a RFID reader which is connected to a 
> RFID tag (object)
> using air interface and HIP Responder can be the information 
> server which
> stores all information of RFID tags. And then, if this 
> information server
> has a role of HIP rendezvous server, a client can directly 
> connect to an
> object behind RFID reader.

I did not understand your last sentence.  You said the HIP initiator is
the RFID reader, but then you mention clients that connect to objects
behind the RFID reader.  
- who is the initiator and the responder?
- what role is the rendezvous server performing?  For other clients who
want to contact the RFID reader but don't know what its current address
is?

Also, what do you mean to connect to an object behind RFID reader?  What
object (the tag)?  And what protocol is used end-to-end?

> 
> - does the RFID reader have a host identity that maps to many object
> identities, or is it one-to-one?
> 
> The RFID reader has one-to-many mapping relationship. So, a 
> host identity of
> RFID reader maps onto many object identities.
> 
> - how is the binding between object identity and host 
> identity secured,
> if at all?
> 
> For this point, I do not have any idea at this moment.
> 
> - what would be the syntax of representing the Object ID (RFID) in the
> HIP protocol data structures?
> 
> There is an EPC (Electronic Product Code) for RFID tag. An 
> EPC is simply a
> number assigned to an RFID tag representative of an actual electronic
> product code. Their value is that they have been carefully 
> characterized and
> categorized to embed certain meanings within their structure 
> which include
> header, EPC manager number, object class number, and serial number.
> 
> - are you concerned about the use case of HIP running over a network
> that is not IP-based?  If so, what is HIP establishing if not IPsec
> security associations?
> 
> For IPsec security associations, HIP will definitely be 
> terminated at the
> RFID reader because HIP should be tightly coupled with network layer.
> Similar with objects inside server, although each object is 
> located remotely
> through air interface with RFID reader, we would like to consider RFID
> reader and tag as the same node virtually. 
> In this case, we can consider two solutions. 
> The one is to put new name space (i.e., object identity) on 
> top of HIP with
> RFID reader. This is the same with case #1 in our document. 
> The other is that object identity replaces host identity on 
> top of network
> layer of RFID reader as we originally suggested (case #2). 
> However, if we
> keep the existing Host_ID as we discussed, this one should be 
> reviewed one
> more time.
> 

In the case where you have a mapping of one host identity to many object
ids, I think that what you are asking for is the ability to separate the
communications at the granularity of an object, not at the granularity
of host id.

That is, in your draft, you are looking for the ability to put an object
identity tag in as a replacement for a host identity tag, so that the
security association would then be from object to object.  If you were
to do as I previously suggested and encode the object identity in the
domain identifier, then you would lose such granularity. 

I think you would like HIP to be adapted so that users could use other
identifiers such as RFID tags and telephone numbers to communicate with
one another.  On a given host, you may have a one-to-one or one-to-many
mapping between host and object ID.  

This would seem to require a mapping service of some sort between host
identifier and object identifier, and also a way to establish channels
between hosts.  A host with two telephone numbers may have one host
identity but you would want the granularity and separation of the data
flows to be at the telephone number level, not the host id level.

You then would probably want some additional granularity in HIP that is
not presently there (the ability that IKEv2 has to establish and
maintain multiple security associations between hosts) plus the ability
to latch these SAs to some higher-level identifiers that you call object
Ids
(see http://tools.ietf.org/html/draft-ietf-btns-connection-latching-06,
although the btns draft is in the context of latching to upper level
transport protocols).

I still think it would help if you were able to describe a specific use
case in great detail, such as "user Ux with telephone number Nx on host
Hx wants to call user Uy at number Ny on host Hy"
- what is the application API, or upper layer protocol, that the
application uses to call Ny?  does it assume UDP, RTP, TCP, etc. on top
of HIP, or make no such assumption?  What identifiers, and how are they
formatted, are passed at the API?

- how does the stack on X, which knows Hx and Ny, know how to find the
corresponding Hy, or is this passed into the stack as part of the API?

- if Hx and Hy already have an active security association set up, can
that be reused, or would you want to see security associations at the
granularity of Nx<->Ny?

Tom

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Wed, 17 Dec 2008 12:35:18 -0800
Subject: [Hipsec-rg] meeting minutes posted
Message-ID: <[email-masked]>

We didn't receive any comments or corrections on the Minneapolis meeting
minutes, so they've been posted to the proceedings page.

- Tom

From: gmlee at icu.ac.kr (Gyu Myoung Lee)
Date: Mon, 15 Dec 2008 13:11:53 +0100
Subject: [Hipsec-rg] discussion of draft-lee-hip-object-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<002701c959d0$ba69df20$2f3d9d60$@gov>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dear All

See detailed answers on questions.

- who (which software processes) is communicating with whom?  A software
process on an RFID reader talking with a centralized controller or
inventory manager, for instance?

HIP Initiator can be a RFID reader which is connected to a RFID tag (object)
using air interface and HIP Responder can be the information server which
stores all information of RFID tags. And then, if this information server
has a role of HIP rendezvous server, a client can directly connect to an
object behind RFID reader.

- does the RFID reader have a host identity that maps to many object
identities, or is it one-to-one?

The RFID reader has one-to-many mapping relationship. So, a host identity of
RFID reader maps onto many object identities.

- how is the binding between object identity and host identity secured,
if at all?

For this point, I do not have any idea at this moment.

- what would be the syntax of representing the Object ID (RFID) in the
HIP protocol data structures?

There is an EPC (Electronic Product Code) for RFID tag. An EPC is simply a
number assigned to an RFID tag representative of an actual electronic
product code. Their value is that they have been carefully characterized and
categorized to embed certain meanings within their structure which include
header, EPC manager number, object class number, and serial number.

- are you concerned about the use case of HIP running over a network
that is not IP-based?  If so, what is HIP establishing if not IPsec
security associations?

For IPsec security associations, HIP will definitely be terminated at the
RFID reader because HIP should be tightly coupled with network layer.
Similar with objects inside server, although each object is located remotely
through air interface with RFID reader, we would like to consider RFID
reader and tag as the same node virtually. 
In this case, we can consider two solutions. 
The one is to put new name space (i.e., object identity) on top of HIP with
RFID reader. This is the same with case #1 in our document. 
The other is that object identity replaces host identity on top of network
layer of RFID reader as we originally suggested (case #2). However, if we
keep the existing Host_ID as we discussed, this one should be reviewed one
more time.

Gyu Myoung Lee

-----Original Message-----
From: Henderson, Thomas R [mailto:thomas.r.henderson at boeing.com] 
Sent: Friday, December 12, 2008 5:36 PM
To: Gyu Myoung Lee
Cc: skjo at etri.re.kr; jkchoi at icu.ac.kr; hipsec-rg at listserv.cybertrust.com
Subject: RE: [Hipsec-rg] discussion of draft-lee-hip-object-01

 

> -----Original Message-----
> From: Gyu Myoung Lee [mailto:gmlee at icu.ac.kr] 
> Sent: Thursday, December 11, 2008 3:07 AM
> To: miika.komu at hiit.fi; Henderson, Thomas R
> Cc: skjo at etri.re.kr; jkchoi at icu.ac.kr; gmlee at icu.ac.kr; 
> hipsec-rg at listserv.cybertrust.com
> Subject: RE: [Hipsec-rg] discussion of draft-lee-hip-object-01
> 
> 
> Dear All
> 
> Origianlly I proposed the extension of "endpoint" to all of 
> objects so that
> each object would be a host. So, I suggested new object identity for
> replacing host identity.
> 
> However, I am not in favor with specific solutions. The most 
> important thing
> is to accomplish the same goals for object-to-object communications.
> 
> If the our proposal has some problems in particular security 
> aspects and we
> want to keep the exisiting Host_ID, as Tom suggested, to specify a new
> Domain Identifier format for the Object ID can be one of good 
> solutions for
> the same objective. In this case, we can also get mapping 
> information for
> each object.

OK, then, a next question I have is how you would envision a specific
use case to be handled.  You had mentioned previously an RFID tag as an
example object.  Typically, these are read by an RFID reader, which I
presume would be the endpoint of communications.  

- who (which software processes) is communicating with whom?  A software
process on an RFID reader talking with a centralized controller or
inventory manager, for instance?
- does the RFID reader have a host identity that maps to many object
identities, or is it one-to-one?
- how is the binding between object identity and host identity secured,
if at all?
- what would be the syntax of representing the Object ID (RFID) in the
HIP protocol data structures?
- are you concerned about the use case of HIP running over a network
that is not IP-based?  If so, what is HIP establishing if not IPsec
security associations?

I think that if you could sketch out with some detail how you envision
one of these specific use cases for your proposal, it would help me and
others to better understand what you would like to see specified.

Tom

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Fri, 12 Dec 2008 08:36:19 -0800
Subject: [Hipsec-rg] discussion of draft-lee-hip-object-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<002701c959d0$ba69df20$2f3d9d60$@gov>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Gyu Myoung Lee [mailto:gmlee at icu.ac.kr] 
> Sent: Thursday, December 11, 2008 3:07 AM
> To: miika.komu at hiit.fi; Henderson, Thomas R
> Cc: skjo at etri.re.kr; jkchoi at icu.ac.kr; gmlee at icu.ac.kr; 
> hipsec-rg at listserv.cybertrust.com
> Subject: RE: [Hipsec-rg] discussion of draft-lee-hip-object-01
> 
> 
> Dear All
> 
> Origianlly I proposed the extension of "endpoint" to all of 
> objects so that
> each object would be a host. So, I suggested new object identity for
> replacing host identity.
> 
> However, I am not in favor with specific solutions. The most 
> important thing
> is to accomplish the same goals for object-to-object communications.
> 
> If the our proposal has some problems in particular security 
> aspects and we
> want to keep the exisiting Host_ID, as Tom suggested, to specify a new
> Domain Identifier format for the Object ID can be one of good 
> solutions for
> the same objective. In this case, we can also get mapping 
> information for
> each object.

OK, then, a next question I have is how you would envision a specific
use case to be handled.  You had mentioned previously an RFID tag as an
example object.  Typically, these are read by an RFID reader, which I
presume would be the endpoint of communications.  

- who (which software processes) is communicating with whom?  A software
process on an RFID reader talking with a centralized controller or
inventory manager, for instance?
- does the RFID reader have a host identity that maps to many object
identities, or is it one-to-one?
- how is the binding between object identity and host identity secured,
if at all?
- what would be the syntax of representing the Object ID (RFID) in the
HIP protocol data structures?
- are you concerned about the use case of HIP running over a network
that is not IP-based?  If so, what is HIP establishing if not IPsec
security associations?

I think that if you could sketch out with some detail how you envision
one of these specific use cases for your proposal, it would help me and
others to better understand what you would like to see specified.

Tom

From: gmlee at icu.ac.kr (Gyu Myoung Lee)
Date: Thu, 11 Dec 2008 12:07:27 +0100
Subject: [Hipsec-rg] discussion of draft-lee-hip-object-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<002701c959d0$ba69df20$2f3d9d60$@gov>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dear All

Origianlly I proposed the extension of "endpoint" to all of objects so that
each object would be a host. So, I suggested new object identity for
replacing host identity.

However, I am not in favor with specific solutions. The most important thing
is to accomplish the same goals for object-to-object communications.

If the our proposal has some problems in particular security aspects and we
want to keep the exisiting Host_ID, as Tom suggested, to specify a new
Domain Identifier format for the Object ID can be one of good solutions for
the same objective. In this case, we can also get mapping information for
each object.

Gyu Myoung Lee

-----Original Message-----
From: hipsec-rg-bounces at listserv.cybertrust.com
[mailto:hipsec-rg-bounces at listserv.cybertrust.com] On Behalf Of Miika Komu
Sent: Thursday, December 11, 2008 9:45 AM
To: Henderson, Thomas R
Cc: skjo at etri.re.kr; jkchoi at icu.ac.kr; Gyu Myoung Lee;
hipsec-rg at listserv.cybertrust.com
Subject: Re: [Hipsec-rg] discussion of draft-lee-hip-object-01

Henderson, Thomas R wrote:

Hi,

>> -----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.

I would be in favor of reusing the current format of host ids as 
suggested by Tom.

_______________________________________________
Hipsec-rg mailing list
Hipsec-rg at listserv.cybertrust.com
https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg

From: miika.komu at hiit.fi (Miika Komu)
Date: Thu, 11 Dec 2008 10:44:52 +0200
Subject: [Hipsec-rg] discussion of draft-lee-hip-object-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <002701c959d0$ba69df20$2f3d9d60$@gov> <[email-masked]>
Message-ID: <[email-masked]>

Henderson, Thomas R wrote:

Hi,

>> -----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.

I would be in favor of reusing the current format of host ids as 
suggested by Tom.

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
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: <[email-masked]> <[email-masked]> <002701c959d0$ba69df20$2f3d9d60$@gov>
Message-ID: <[email-masked]>

> -----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

From: gmlee at icu.ac.kr (Gyu Myoung Lee)
Date: Tue, 9 Dec 2008 14:44:18 +0100
Subject: [Hipsec-rg] discussion of draft-lee-hip-object-01
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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.

Gyu Myoung Lee

-----Original Message-----
From: hipsec-rg-bounces at listserv.cybertrust.com
[mailto:hipsec-rg-bounces at listserv.cybertrust.com] On Behalf Of Miika Komu
Sent: Monday, December 08, 2008 6:17 PM
To: hipsec-rg at listserv.cybertrust.com
Subject: Re: [Hipsec-rg] discussion of draft-lee-hip-object-01

Henderson, Thomas R wrote:

Hi,

I would be in favor of adding the document as an RG item although more 
work is needed as indicated by the meeting notes.

> All,
> In Minneapolis, we also discussed, at length, the Object-to-Object
> communications draft:
> http://tools.ietf.org/html/draft-lee-hip-object-01
> 
> The authors are likewise asking the RG for feedback and for whether the
> RG would like to adopt this as a work item.
> 
> The discussion at the meeting is summarized in the meeting minutes:
> https://listserv.cybertrust.com/pipermail/hipsec-rg/2008-December/000538
> .html
> 
> To summarize the meeting discussion, several people expressed interest
> in the basic concept proposed, which is to generalize HIP to allow other
> objects (besides internet stacks) to be named, although there was some
> debate as to whether the draft proposes the right mechanisms for this.
> However, there were also a few comments that the use cases are not well
> defined, such that some people had trouble understanding exactly what is
> being proposed and why. 
> 
> Again, please provide feedback on the draft and on whether you think the
> RG should actively work this item.
> 
> - Tom
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg

_______________________________________________
Hipsec-rg mailing list
Hipsec-rg at listserv.cybertrust.com
https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg

From: miika.komu at hiit.fi (Miika Komu)
Date: Mon, 08 Dec 2008 19:17:12 +0200
Subject: [Hipsec-rg] discussion of draft-lee-hip-object-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Henderson, Thomas R wrote:

Hi,

I would be in favor of adding the document as an RG item although more 
work is needed as indicated by the meeting notes.

> All,
> In Minneapolis, we also discussed, at length, the Object-to-Object
> communications draft:
> http://tools.ietf.org/html/draft-lee-hip-object-01
> 
> The authors are likewise asking the RG for feedback and for whether the
> RG would like to adopt this as a work item.
> 
> The discussion at the meeting is summarized in the meeting minutes:
> https://listserv.cybertrust.com/pipermail/hipsec-rg/2008-December/000538
> .html
> 
> To summarize the meeting discussion, several people expressed interest
> in the basic concept proposed, which is to generalize HIP to allow other
> objects (besides internet stacks) to be named, although there was some
> debate as to whether the draft proposes the right mechanisms for this.
> However, there were also a few comments that the use cases are not well
> defined, such that some people had trouble understanding exactly what is
> being proposed and why. 
> 
> Again, please provide feedback on the draft and on whether you think the
> RG should actively work this item.
> 
> - Tom
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Mon, 8 Dec 2008 08:38:10 -0800
Subject: [Hipsec-rg] discussion of draft-lee-hip-object-01
Message-ID: <[email-masked]>

All,
In Minneapolis, we also discussed, at length, the Object-to-Object
communications draft:
http://tools.ietf.org/html/draft-lee-hip-object-01

The authors are likewise asking the RG for feedback and for whether the
RG would like to adopt this as a work item.

The discussion at the meeting is summarized in the meeting minutes:
https://listserv.cybertrust.com/pipermail/hipsec-rg/2008-December/000538
.html

To summarize the meeting discussion, several people expressed interest
in the basic concept proposed, which is to generalize HIP to allow other
objects (besides internet stacks) to be named, although there was some
debate as to whether the draft proposes the right mechanisms for this.
However, there were also a few comments that the use cases are not well
defined, such that some people had trouble understanding exactly what is
being proposed and why. 

Again, please provide feedback on the draft and on whether you think the
RG should actively work this item.

- Tom

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Mon, 8 Dec 2008 08:22:43 -0800
Subject: [Hipsec-rg] discussion of draft-cao-hip-geolocation-01
Message-ID: <[email-masked]>

All,
As we discussed in Minneapolis, the authors of draft-cao-hip-geolocation
(Delivering Geographic Location in HIP) have asked both for feedback
from the RG on their proposal and for whether the RG is interested in
taking the draft as a RG work item.  The draft is located at:
http://tools.ietf.org/html/draft-cao-hip-geolocation-01

There was a good bit of discussion at the meeting, summarized in the
meeting minutes:
https://listserv.cybertrust.com/pipermail/hipsec-rg/2008-December/000538
.html

To summarize, the draft proposes that HIP provide a service that carries
geolocation information between hosts.  In the RG meeting, there was
some support expressed for the basic concept.  There were also some
concerns expressed about privacy, about whether HIP is the right layer
to provide this information, and about defining the use cases in more
detail.

Please comment or ask questions about the technical details, and comment
on whether you think the RG should adopt this work item (by adopting it,
it would mean that more people than the initial authors would need to
get involved in progressing it further).

- Tom

p.s. I will forward this message to the GEOPRIV mailing list, so that
interested parties can subscribe and discuss here (to avoid
cross-posting).

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Thu, 4 Dec 2008 11:10:26 -0800
Subject: [Hipsec-rg] IETF 73 meeting minutes
Message-ID: <[email-masked]>

Attached are the draft IETF 73 meeting minutes.  Please review them and
send corrections before Dec. 15.  Thanks to Andrew McGregor for
compiling them.

There are two items from the meeting that need further list discussion;
namely, what the RG would like to do next with two drafts that were
presented at the meeting:
1) HIP Extensions for Object-to-Object Communications
2) Delivering Geographic Location in HIP

Please review what was discussed about these two drafts, and we can
start separate threads to discuss them.

- Tom

p.s. note that slides from the IETF meeting are archived here:
https://datatracker.ietf.org/meeting/73/materials.html
and meeting audio is archived here:
ftp://videolab.uoregon.edu/pub/videolab/media/ietf73/ietf73-ch7-fri-am.m
p3
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hiprg-minutes-ietf73.txt
URL: <https://listserv.cybertrust.com/pipermail/hipsec-rg/attachments/20081204/dfdff548/attachment.txt>

From: gurtov at cs.helsinki.fi (Andrei Gurtov)
Date: Thu, 04 Dec 2008 15:57:02 +0200
Subject: [Hipsec-rg] workshop at MobiSec?
Message-ID: <[email-masked]>

There is going to be a HIP tutorial at coming MobiSec'09 conference in
June in Italy. The organizers also want to have a small workshop on HIP
after the tutorial. Perhaps someone from HIP community would like to
give a speech? Bob, Tom?

http://www.mobisec.org/
http://www.mobisec.org/tutorial.shtml

Andrei