Already in HIP there has been some struggle with what AID to pass
to applications, and some level of discomfort with passing non
routable values posing as IP addresses to legacy apps, for many of
the reasons cited in the previous posts (see also Appendix A of
the draft HIP base spec). For legacy APIs and legacy apps, then,
maybe this kind of AID/m6 identifier split could satisfy
the referral issue, or perhaps instead being underpinned by WIMP
or other lighter-weight m6 identifier, as you and Erik suggest.
Tom
I have concentrated on the ephemeral identifiers concept and
tried to figure out their properties in different scenarios.
The ephemeral identifiers are useful with one-way
hash chain authentication, when establishing a state.
An attacker cannot easily steal a context identifier in this way.
However, because the presented ephemeral namespace is flat
and not routable from its nature, it does not solve the referral
problem. Now, if we conceptually separate AIDs from wedge 3.5
layer Context Identifiers (let them be called as CIDs), we still end
up with AID ownership problems. The security problems related
to wedge layer context theft and application layer identifier theft
are slightly different, but they are mostly similar with each other.
What comes to the current WIMP work, is that we are making
an exercise to understand the relationship between routable AIDs,
ephemeral CIDs, and hash chains. I like to notice that the work is
not the final editorial effort to combine group-F protocols as
requested
by co-chairs. Before that, we should start naming the different
components
in different group-F proposals, and evaluate the components against the
things-to-think-about and security-threats drafts, if possible.
At this point of time, while our exercise is still under work, I have
a feeling that a routable AID should have cryptographical properties
that can be used to prove the ownership of that AID; if we do not want
to rely on the DNS. The properties are based on the public key
cryptography.