Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00: Includinghieararchy in HIT generation

[Xu Xiaohu <[e-mail]>]

===It seems that my preview email is not posted to the HIPRG mailing-list
successfully, so I resend it.====

Hi all,

IMHO, one can directly use the CGA mechanism with small changes, rather than
a new algorithm as mentioned by Tobias, to generate hierarchical and
cryptographic host identifiers. In fact, we have already been using the CGA
mechanism to generate host identifiers in our RANGI proposal
(http://tools.ietf.org/html/draft-xu-rangi-01). The following is the quote
from that proposal. For more information, please read that draft.

"The approach of generating hierarchical host identifiers in RANGI is much
similar to the Cryptographically Generated Addresses (CGA) [RFC3972]. The
major difference is that the prefix of the RANGI host identifier is AD ID,
rather than ordinary IPv6 address prefix. In the CGA, the process of
generating a new CGA takes three input values: a 64-bit subnet prefix, the
public key of the address owner as a DER-encoded ASN.1 structure of the type
SubjectPublicKeyInfo and the security parameter Sec, which is an unsigned
three-bit integer. In RANGI, the process of generating a new host identifier
also takes three input values: the n-bit AD ID (the suitable value of ”n”
has not been determined), the public key of the host ID owner and the
security parameter Sec."

However, as stated in the CGA [RFC 3972], "...because CGAs themselves are
not certified, an attacker can create a new CGA from any subnet prefix and
its own (or anyone else's) public key.  However, the attacker cannot take a
CGA created by someone else and send signed messages that appear to come
from the owner of that address... ". Hence, in order to verify the
association between the prefix and the address owner, we need some other
means, e.g., a certification issued by a third-party authority, or resorting
to such an authority for verification if necessary.

For the privacy of identifier's organizational affiliation (i.e.,
Administrative Domain), maybe the two communicating parties could use the
hierarchical identifier to find the opposing party's locator in a
hierarchical id/locator mapping system, then use the self-certified flat HIT
instead for subsequent communication if the privacy is necessary.

Xiaohu

> -----邮件原件-----
> 发件人: Xu Xiaohu [mailto:[e-mail]]
> 发送时间: 2009年8月11日 12:02
> 收件人: 'Henderson, Thomas R'; 'Tobias Heer'; '[e-mail]'
> 抄送: '[e-mail]'
> 主题: 答复: [hiprg] draft-zhang-hip-hierarchical-parameter-00:
> Includinghieararchy in HIT generation
> 
> Hi all,
> 
> IMHO, one can directly use the CGA mechanism with small changes, rather
than
> a new algorithm as mentioned by Tobias, to generate hierarchical and
> cryptographic host identifiers. In fact, we have already been using the
CGA
> mechanism to generate host identifiers in our RANGI proposal
> (http://tools.ietf.org/html/draft-xu-rangi-01). The following is the quote
> from that proposal. For more information, please read that draft.
> 
> "The approach of generating hierarchical host identifiers in RANGI is much
> similar to the Cryptographically Generated Addresses (CGA) [RFC3972]. The
> major difference is that the prefix of the RANGI host identifier is AD ID,
rather
> than ordinary IPv6 address prefix. In the CGA, the process of generating a
new
> CGA takes three input values: a 64-bit subnet prefix, the public key of
the
> address owner as a DER-encoded ASN.1 structure of the type
SubjectPublicKeyInfo
> and the security parameter Sec, which is an unsigned three-bit integer. In
RANGI,
> the process of generating a new host identifier also takes three input
values:
> the n-bit AD ID (the suitable value of ”n” has not been determined), the
public
> key of the host ID owner and the security parameter Sec."
> 
> However, as stated in the CGA [RFC 3972], "...because CGAs themselves are
not
> certified, an attacker can create a new CGA from any subnet prefix and its
own
> (or anyone else's) public key.  However, the attacker cannot take a CGA
created
> by someone else and send signed messages that appear to come from the
owner
> of that address... ". Hence, in order to verify the association between
the
> prefix and the address owner, we need some other means, e.g., a
certification
> issued by a third-party authority, or resorting to such an authority for
> verification if necessary.
> 
> For the privacy of identifier's organizational affiliation (i.e.,
> Administrative Domain), maybe the two communicating parties could use the
> hierarchical identifier to find the opposing party's locator in a
hierarchical
> id/locator mapping system, then use the self-certified flat HIT instead
for
> subsequent communication if the privacy is necessary.
> 
> Xiaohu
> 
> > -----邮件原件-----
> > 发件人: Henderson, Thomas R [mailto:[e-mail]]
> > 发送时间: 2009年8月11日 0:13
> > 收件人: Tobias Heer; [e-mail]; Xu Xiaohu
> > 抄送: [e-mail]
> > 主题: RE: [hiprg] draft-zhang-hip-hierarchical-parameter-00:
> > Includinghieararchy in HIT generation
> >
> >
> >
> > > -----Original Message-----
> > > From: Tobias Heer [mailto:[e-mail]]
> > > Sent: Tuesday, July 28, 2009 6:02 AM
> > > To: [e-mail]; Xu Xiaohu
> > > Cc: [e-mail]
> > > Subject: [hiprg] draft-zhang-hip-hierarchical-parameter-00:
> > > Includinghieararchy in HIT generation
> > >
> > > Hi!
> > >
> > > I just wanted to clarify my comment in the HIPRG meeting on
> > > including
> > > the hierarchy in the HIT creation process. I think it would
> > > be good to
> > > have the hierarchy information in the HIT creation process
> > > because the
> > > hierarchy will be bound to the HIT itself.
> > >
> > > Below I briefly sketched a possible way of including it without
> > > revealing the hierarchy to all hosts.
> > >
> > > HIT generation could work like this:
> > >
> > > 1. Pick random secret X
> > >
> > > 2. H(Hierarchy, X) => HTag
> > >
> > > 3. H(PubKey, ..., HTag) => HIT (Orchid)
> > >
> > > --> Only use LTag if you do not want to reveal hierarchy.
> > > --> Use hierarchy and X if you want to reveal the hierarchy.
> >
> > Hi Tobias,
> >
> > I recently had a chance to listen to the audio archive of the meeting
> > and I'm reviewing the mail now.  Can you explain in more detail what is
> > the use case for what you are proposing?  I thought that the draft was
> > mainly concerned with having publicly revealed hierarchies so that
> > reverse lookups could exploit hierarchy.  In your proposal above, for
> > the observer who knows X, how does such observer retrieve hierarchy
> > bits, given the HIT, HTag, and X?
> >
> > Also, I am not sure you can claim that the result from your above is a
> > HIT, because according to RFC4843 and 5201, a HIT is formed without
> > these HTags.  In particular, the HIT would no longer be able to be
> > associated to the key, for an observer who does not know the magic HTag
> > to apply.
> >
> > Tom