Subject: [core] A 'new' view in use of RawPublicKeys in Core and elsewhere

From: Robert Moskowitz <[email-masked]>
Date: Thu, 22 Mar 2012 18:06:58 +0100

First I am in Stockholm right now after a meeting with a Verizon ISV 
(Wow, real company work :) ).  I will be arriving in Paris sunday 
noonish and leaving thursday afternoon.

Second, what I am about to present has been the outgrowth of 
conversations and emails during and after the IEEE 802 meeting last 
week, from people in both 802.11ai and 802.15.9.

Paul Lambert (Marvel) made a short presentation to the 802.11 wng 
session on 'Key Centric Identity' to get the larger 802.11 community 
into an understanding of discussions ongoing in 802.11ai, this is at:

https://mentor.ieee.org/802.11/dcn/12/11-12-0378-00-0wng-key-centric-identity.ppt

Very short and to the point and content (other than the hash used as a 
local MAC address) should be familiar with people on this list.  But a 
couple of key points is that the public key IS the identity and a hash 
of that key IS a powerful tool to authentication services.  Now although 
I am a big proponent of KCI for over 12 years, only recently have I 
worked out some key environmental portions and some still needs some 
work (as well as being ECC centric).

Enough background.

Premise:  The sensor and a network service (To Be Named) both have 
RawPublicKey Identities that are available in a hashed format.  I will 
call these RpkI and RpkHI until someone gives me better generic handles 
(I want to avoid HIP-style labels).

Further the sensor's RpkHI and some other information (Some to be 
discussed further down) will be printed on the sensor or on provided 
paper in a QR code (probably v3 should be enough).  The QR code will be 
used to preload the network authentication server with the sensor's 
identity as Paul shows.  I will not discuss here (though I am elsewhere) 
the protocol used by the network service and the authentication service 
to retrieve valid sensor RpkHI.  This deployment method provides one 
side of the problem on how the network service accept a new sensor.

For the other side, how does the sensor recognize the proper PAN and 
service, I am going to introduce some things that are rather 'new' to 
me, and I may not have all the pieces right and so far I only know how 
to do this with EC identities like static ECDH (though ECDSA works as 
well).  The piece here is ECQV, Implicit Certificates, that was just 
shown to me last week by Andrei Gutov for his student, Jani Pellikka.  
Here the sensor vendor pre-loads the sensor with the random value need 
for the ECQV and places that in the QR code.  The network authentication 
server takes that and the network service identity and builds the ECQV 
to use in the KMP.  It is ASSUMEd that only the intended PAN has this 
information (thus there is a weakness of leakage here for who scans the 
QR code).  Now the sensor can validate the RpkHI in the form of the ECQV 
it got.  Not 100%, but much closer than anything else I have worked out.

There is always the backoff and retry approach if the neighboring PAN is 
able to make the same ECQV (you picked the room thermometer out of your 
neighbor's garbage, shame on you).  I also have only seen this with ECC.

I am in the process of working this out.  Some of it I only really put 
together last week, and really the ECQV in this direction in this manner 
only came to me a couple hours ago rereading the 'RawPublicKeys' thread 
on this list.

I offer this for your reading pleasure.  I have my preferred KMP and I 
fully intend to pursue this, but I believe this will work with MOST KMPs 
that implement support for RpkHI.

Finally, I will point out what I view as obvious.  The world of sensor 
networks is not all CoAP, let alone 6lowpan and even Zigbee.  LECIM 
(802.15.4k) looks to be fun.  And now we have the PTC SG with a PAR 
(just a different set of challenges).  Thus I am working on the network 
securing and authentication in 802.15.9 where I believe it needs to 
live.  Oh and it looks like there is life still in 802.15.7 based on a 
presentation last week.

See people Sunday afternoon or later.

---

From: Rene Struik <[email-masked]>
Date: Thu, 22 Mar 2012 14:07:46 -0400

Hi Bob:

I have been struggling with the equation PubKey = Identity for a long
time and will continue to do so till someone can explain to me how one
can speak of "the" identity in this case in settings where the public
key (or, for that matter, data associated with that public key) may
change during the lifecycle of the device. Moreover, it may very well be
the case that initial public keys are only generated after the need to
communicate the identifier becomes available.

Some deployment scenarios where public key related info may change over
time:
1) short-lived certificates (as would, e.g., be the case with ECQV
certs, where the reconstructed public key depends on all data field of
the to-be-signed data, including public key reconstruction data and
policy fields, such as key validity time period).
2) public keys certified by more than one entity (although I have not
looked into this in detail, shouldn't one then bind the public key to
the binding entity and not "cut the ties"?).
3) delegation of public keys, e.g., in the event one may authenticate
via more than one device.

To me, it seems that having a certificate provides for the binding of an
entity's identity to (the private key corresponding to) a public key, so
we have a mechanism that has been around for decades that allows
definition of identities and public keys in orthogonal fashion, withou
hardcoding one in terms of the other.

Isn't the real reason to bring this up then that one does not believe in
certificates, find them unmanageable, bulky, etc.? There are easy fixes
here (e.g., short-lived certificates, which may take a whole cottage
industry of CRL, OCSP etc. specs out of business), so I would suggest
that would also be a valuable approach --- if my speculation on
underlying cause of bringing up the PubKey = Identity "equation" has
some merit (I bet a bottle of Bordeaux there is some truth in this...).

==
Some earlier CoRE traffic on this:

{Hannes Tschofenig, December 20, 2011}
http://www.ietf.org/mail-archive/web/core/current/msg02543.html

{Rene Struik, Alper Yegin, December 19, 2012}
http://www.ietf.org/mail-archive/web/core/current/msg02540.html

On 22/03/2012 1:06 PM, Robert Moskowitz wrote:
> of that key IS a powerful tool to authentication services.  Now
> although I am a big proponent of KCI for over 12 years, only recently
> have I worked out some key environmental portions and some still needs
> some work (as well as being ECC centric).
>
> Enough background.
>
> call these RpkI and RpkHI until someone gives me better generic
> handles (I want to avoid HIP-style labels).
>
> paper in a QR code (probably v3 should be enough).  The QR code will
> be used to preload the network authentication server with the sensor's
> identity as Paul shows.  I will not discuss here (though I am
> elsewhere) the protocol used by the network service and the
> authentication service to retrieve valid sensor RpkHI.  This
> deployment method provides one side of the problem on how the network
> service accept a new sensor.
>
> for the ECQV and places that in the QR code.  The network
> authentication server takes that and the network service identity and
> builds the ECQV to use in the KMP.  It is ASSUMEd that only the
> intended PAN has this information (thus there is a weakness of leakage
> here for who scans the QR code).  Now the sensor can validate the
> RpkHI in the form of the ECQV it got.  Not 100%, but much closer than
> anything else I have worked out.
>
> There is always the backoff and retry approach if the neighboring PAN
> is able to make the same ECQV (you picked the room thermometer out of
> your neighbor's garbage, shame on you).  I also have only seen this
> with ECC.
>
> together last week, and really the ECQV in this direction in this
> manner only came to me a couple hours ago rereading the
> 'RawPublicKeys' thread on this list.
>
> fully intend to pursue this, but I believe this will work with MOST
> KMPs that implement support for RpkHI.
>
> (just a different set of challenges).  Thus I am working on the
> network securing and authentication in 802.15.9 where I believe it
> needs to live.  Oh and it looks like there is life still in 802.15.7
> based on a presentation last week.
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 22 Mar 2012 20:10:59 +0100

I have a 6:30am flight to get to so early to bed tonight, but I will try...

> communicate the identifier becomes available.

In practice, all identities have an ephemeral quality.  Eight days after 
my birth my parents named me Reuven Gershon ben Benyomin (spelled in 
Hebrew) and put on my birth certificate Robert Glenn Moskowitz. Now I 
did not see my birth certificate until I was 17 and from the age of 5, I 
was writing my english name as Robert Glen Moskowitz (that I still use 
for legal purposes).

In school I was called Bob Moskowitz and at age 11 for the first time a 
classmate called (this was '61 and not a lot of phone calls were made 
even in suburbia, you WENT to the house) and asked appearently for Bob.  
My 7 year old sister had picked up the phone and I heard her side of the 
conversation, "Bob, there is no Bob here". Click.  My family has always 
only known me as Robert.

Premise #1:  An Identity is ANYTHING you want as long as you can use 
it.  (Think of the singer once known as Prince :) ).

Corollary #1:  A public key portion of a public/private key pair MAY be 
used as an identity in and of itself as long as you can use it.

I can go on for hours and pages about namespaces (I was a member of the 
Namespace Research Group and sat through hours of philosophy of names 
and namespaces) and the role of textual, symbolic, and mathematical names.

Premise #2:  Something added MUST bring value commensurate with its 
cost. (well there is always bric-a-brac out there)

Postulate #1: In M2M secure communications RawPublicKeys are sufficient 
in and of themselves, provided there is a mechanism to authenticate them 
within the domain of their use.  Further the total system cost can be 
minimized by working with RawPublicKeys over other PublicKey methods.

Now are these RpkI provided at owner purchase time or build time?
Do they get changed to some concept of changing (ask me about the Jewish 
practice of adding to a critically sick person's name.  Hint it is 
Mystical) or do they last as long as the silicon does? (or someone runs 
them through a microwave oven!)

The answer to both is yes and no.  You choose what works for you.  
(Premise #1)

For myself, and what I recommend is that the common usage will be 
manufacture installed RpkI that last the life of the device.  
Recognizing that there are special customers out there that will want to 
install their own RpkI and will reprovision them as they deem necessary 
and will pay the freight.

Good night.  See you next week.  Well I will pick up email in Amsterdam 
friday, and MAY reply.

-- 
Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Robert Cragie <[email-masked]>
Date: Fri, 23 Mar 2012 11:35:42 +0000

Bob,

Interesting discussion. I think one important distinction is that with a 
programmable electronic device, it is possible to change its identity, 
in spite of the fact the hardware may persist. I have as yet come across 
this ability in human beings; no matter how much you eschew a former 
moniker, you are still the same person. The Prince story is an 
interesting one - he actually wanted to be known as a 'symbol' but in 
practice (in the UK at least), he became 'TAFKAP' (The Artist Formerly 
Known As Prince). However, he was still the same person - his 
fingerprints would not have changed.

This begs the question whether a programmable electronic device should 
have an immutable identity. If based on public key cryptography, a raw 
public key is the bare minimum, but a certificate has an advantage (when 
use with PKI) of being able to carry additional information (including 
another form of identity) which is attested by another trusted entity. A 
self-signed certificate clearly cannot claim to have attestable fields 
and therefore its properties revert to that of a raw public key. But the 
cost may be worth it in having uniformity in operation.

This immutable device identity should ideally just be used in that 
context and additional tokens should be granted as appropriate for 
further functionality. This is the premise of 802.1AR, with its secure 
device identity concept.

Regarding steering to the correct network - my view so far is that there 
is probably no need to bust a gut on this. A simple shared secret (which 
doesn't have to be particularly secret) is probably adequate, but one 
which is not sent in the context of the wireless network it is 
associated with, i.e. is commissioned out-of-band on the network 
authentication server along with the identity of the joining device. The 
identity of the joining device can be advertised by networks which are 
looking for it, the joining device will then authenticate and this 
secret is then sent at the end of authentication (secured) to the 
joining device. So a honeypot may be able to advertise an eavesdropped 
device identity and even complete authentication but it typically would 
not have shared secret, so the joiner would reject it and look 
elsewhere. I accept this scenario does not work for every situation but 
is effective in the "ESI" (Energy Services Interface) in Smart Energy 
scenario.

Robert

On 22/03/2012 7:10 PM, Robert Moskowitz wrote:
> In practice, all identities have an ephemeral quality.  Eight days 
> after my birth my parents named me Reuven Gershon ben Benyomin 
> (spelled in Hebrew) and put on my birth certificate Robert Glenn 
> Moskowitz. Now I did not see my birth certificate until I was 17 and 
> from the age of 5, I was writing my english name as Robert Glen 
> Moskowitz (that I still use for legal purposes).
>
> In school I was called Bob Moskowitz and at age 11 for the first time 
> a classmate called (this was '61 and not a lot of phone calls were 
> made even in suburbia, you WENT to the house) and asked appearently 
> for Bob.  My 7 year old sister had picked up the phone and I heard her 
> side of the conversation, "Bob, there is no Bob here". Click.  My 
> family has always only known me as Robert.
>
> Corollary #1:  A public key portion of a public/private key pair MAY 
> be used as an identity in and of itself as long as you can use it.
>
> I can go on for hours and pages about namespaces (I was a member of 
> the Namespace Research Group and sat through hours of philosophy of 
> names and namespaces) and the role of textual, symbolic, and 
> mathematical names.
>
> Postulate #1: In M2M secure communications RawPublicKeys are 
> sufficient in and of themselves, provided there is a mechanism to 
> authenticate them within the domain of their use.  Further the total 
> system cost can be minimized by working with RawPublicKeys over other 
> PublicKey methods.
>
>
> Do they get changed to some concept of changing (ask me about the 
> Jewish practice of adding to a critically sick person's name.  Hint it 
> is Mystical) or do they last as long as the silicon does? (or someone 
> runs them through a microwave oven!)
>
> Recognizing that there are special customers out there that will want 
> to install their own RpkI and will reprovision them as they deem 
> necessary and will pay the freight.
>
> Good night.  See you next week.  Well I will pick up email in 
> Amsterdam friday, and MAY reply.
>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 23 Mar 2012 17:36:46 +0100

On 03/23/2012 12:35 PM, Robert Cragie wrote:
> Bob,
>
> Interesting discussion. I think one important distinction is that with 
> a programmable electronic device, it is possible to change its 
> identity, in spite of the fact the hardware may persist. I have as yet 
> come across this ability in human beings; no matter how much you 
> eschew a former moniker, you are still the same person. The Prince 
> story is an interesting one - he actually wanted to be known as a 
> 'symbol' but in practice (in the UK at least), he became 'TAFKAP' (The 
> Artist Formerly Known As Prince). However, he was still the same 
> person - his fingerprints would not have changed.

Oh, I am aware of more cases, including ones that alter base bio 
signatures (police have long had to deal with altered fingerprints), but 
no need.  Rather I wanted to get people to see my position that an 
'thing' is useful as an identity if you have a way to use it.  And it 
may be used only in a limited context.

> public key is the bare minimum, but a certificate has an advantage 
> (when use with PKI) of being able to carry additional information 
> (including another form of identity) which is attested by another 
> trusted entity. A self-signed certificate clearly cannot claim to have 
> attestable fields and therefore its properties revert to that of a raw 
> public key. But the cost may be worth it in having uniformity in 
> operation.

There are sensor scenarios where a certificate brings value and there 
scenarios where they don't  I just don't see the value of a certificate 
in a thermometer or a light switch.  Granted they have additional 
information like what room are they in, but that binding does not need 
to be placed in a cert.

I am NOT against certs or PKI, I have enough history with them to know 
that there are scenarios that can only be met with certs.  But likewise 
I want to see the non-cert pk, ie RawPublicKey, approah be provided for 
as well.

Now think about LECIM where the local DOT is imbedding hundreds of 
sensors in the roadbed that will communicate with the controller up to 
10KM away (look at the 15.4k PAR).  We don't want a malicious person 
claiming that the road is icy when it is clear; trusted identity is 
valueable here.  But considering the various factors, what does the 
sensor need in it and what can be handled in the app as provisioning?

In PTC, how much time does the train have to validate the identity of a 
sensor?  Granted there are only 25,000 trains on the US system and we 
can throw an extra $1000 into computing power on each train.  But what 
about the gate crossing actuator?  Implicit Certs like ECQV can make a 
real difference.

The real point here is we cannot forecast all the uses.  We do know 
there are very constrained uses.  We are encouraged to see how small can 
we go.  Rule #12 in RFC 1925, perhaps.

> further functionality. This is the premise of 802.1AR, with its secure 

I know, I worked early on on 1AR.  It again has applicability, but how 
does a homeowner that has minimual computer skills load one with their 
specific needs into the light switch for the back hallway?  Put the 
information into the AAA server.  Actually I like LDAP over AAA, but 
that opens yet another can of worms.

>
> Regarding steering to the correct network - my view so far is that 
> there is probably no need to bust a gut on this. A simple shared 
> secret (which doesn't have to be particularly secret) is probably 
> adequate, but one which is not sent in the context of the wireless 
> network it is associated with, i.e. is commissioned out-of-band on the 
> network authentication server along with the identity of the joining 
> device. The identity of the joining device can be advertised by 
> networks which are looking for it, the joining device will then 
> authenticate and this secret is then sent at the end of authentication 
> (secured) to the joining device. So a honeypot may be able to 
> advertise an eavesdropped device identity and even complete 
> authentication but it typically would not have shared secret, so the 
> joiner would reject it and look elsewhere. I accept this scenario does 
> not work for every situation but is effective in the "ESI" (Energy 
> Services Interface) in Smart Energy scenario.

No way to get the shared secret into a light switch.  So the light 
switch comes with a joining password, if you will. This password can be 
used within the KMO as a password, or in SAE, or ECQV.

There are sensors that can be provisioned before installed, and there 
are those that can't.

>> for Bob.  My 7 year old sister had picked up the phone and I heard 
>> her side of the conversation, "Bob, there is no Bob here". Click.  My 
>> Jewish practice of adding to a critically sick person's name.  Hint 
>> it is Mystical) or do they last as long as the silicon does? (or 
>> someone runs them through a microwave oven!)
>>