Subject: Re: [Ace] New Version of Proposed Charter

From: Olaf Bergmann <[email-masked]>
Date: Mon, 03 Feb 2014 11:52:39 +0100

Paul Lambert <[email-masked]> writes:

> Secure introduction in this context (one device to another) assumes
> some common secret based intermediary.  Secret based architectures
> tend to assume an always-on Internet connection to get to secret based
> authentication servers.  Local symmetric key authentication is
> possible with simple shared keys … (e.g. today’s WPA2-Personal for
> APs).  This appears useful or small groups and home applications - but
> adds the complexity of password based enrollment.  Alternatives to
> password based enrollment (WPS2, WPS3, etc) start to use public key
> exchanges to improve the user experience.  Simply starting with
> asymmetric based identities in devices would greatly simplify the
> architecture allowing better distributed/P2P interactions that are not
> dependant on server or services.
>
> So I still hold to the original statement -> "Symmetric solutions do
> not scale.” ….  but. ‘scale’ needs to be viewed in the context of my
> view of the use cases.  My requirements/use cases are for ubiquitous
> P2P authentication/authorization. No authentication servers can be
> involved.  My thermostat should not have to talk to a CA or remote
> authentication server to read a new temperature sensor.

Fair enough. This sounds like a reasonable use-case that should be
looked at in this working group.

Gruesse
Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 03 Feb 2014 14:57:56 +0100

> looked at in this working group.

Just a few questions so I understand more of this case:

Couldn't that be solved by provisioning static ACLs to the new 
temperature sensors?
If so I don't think ACE should spend time duplicating work done in OMA 
LW M2M.

Further: do you expect that the thermostat would be able to perform 
asymmetric crypto operations? Seems rather heavy to me for a tiny little 
mote. A temperature sensor would most likely be a class 0 device (by 
lwig terminology).

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 03 Feb 2014 13:32:09 +0100

Paul Lambert <[email-masked]> writes:

> Clearly we have a cellular system based on authentication with secrets
> that obviously scales.  We have web based password authentication that
> obviously scales.  However, these always include central servers from
> some provider of some variety that maintains the secret keys (often
> password based).
>

Gruesse
Olaf

---

From: Paul Lambert <[email-masked]>
Date: Mon, 3 Feb 2014 10:10:27 -0800

On Feb 3, 2014, at 5:57 AM, Ludwig Seitz <[email-masked]> wrote:

> Couldn't that be solved by provisioning static ACLs to the new temperature sensors?
Not sure while an ACL goes in the temperature sensor.

> If so I don't think ACE should spend time duplicating work done in OMA LW M2M.
I do not see this specifciation in the open OMA documents - do you have a pointer?

If OMA is the solution, why bother with working in the IETF …    :-)

More seriously - I’m only pointing out the mistake of continuing to mandate authentication systems based on shared secrets when we should be using public keys.  Any data schemas from OMA would be orthogonal.

> 
> Further: do you expect that the thermostat would be able to perform asymmetric crypto operations?
Yes.

> Seems rather heavy to me for a tiny little mote.
No. ECC is already in smart cards.  

> A temperature sensor would most likely be a class 0 device (by lwig terminology).
Yes - totally feasible to use asymmetric crypto in class 0 devices.  Actually makes such products easier to use.

Paul

> 
> /Ludwig
> 
> 
> -- 
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelevägen 17
> SE-223 70 Lund
> 
> Phone +46(0)70-349 92 51
> http://www.sics.se
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 5 Feb 2014 12:57:01 +0100 (CET)

I think we should avoid statements like "Symmetric keys don't scale" since they are obviously wrong, as noted in the email further below.

What you want to say is that you don't like some of the properties of symmetric keys for your use case, for example the use of a trusted third party. That's a completely different story. 

Note, however, that all solutions submitted to the group I have seen so far require a trusted third party (TTP) in some form. The difference is only how often they have to contact that TTP. 

You write: "My thermostat should not have to talk to a CA or remote authentication server to read a new temperature sensor."  If you allow everyone to read the temperature then that might be fine but you may want to  
a) get a certificate (or symmetric key) at some point in time to the thermostat so that it can interact with the other devices, 
b) you might want to have a story for revoking the key, 
c) you might also want to have access control policies configured that tell you which device is allowed to access which resources, 
d) you may not want to use the same keying material forever (for many reasons, including privacy, and performance).

Hence, there is the question why the thermostat shouldn't talk to a trusted third party. That party might even be in your local network, or in the same administrative domain (e.g., enterprise network); it does not need to be in the "cloud". 

Furthermore, one should also think about how many solution variants this group wants to develop. More variants means less interoperability and more complexity. 
Imagine if you have a version that uses symmetric cryptography and another one that uses asymmetric cryptography. Obviously, a device implementing the symmetric variant will not be able to talk to a device that uses the asymmetric variant (unless that device implements both variants). 

Ciao
Hannes

Gesendet: Montag, 03. Februar 2014 um 12:32 Uhr
Von: "Olaf Bergmann" <[email-masked]>
An: "Paul Lambert" <[email-masked]>
Cc: "Stefanie Gerdes" <[email-masked]>, "Bert Greevenbosch" <[email-masked]>, "Göran Selander" <[email-masked]>, "[email-masked]" <[email-masked]>
Betreff: Re: [Ace] New Version of Proposed Charter

Gruesse
Olaf

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Feb 2014 12:04:58 -0500

Hannes Tschofenig <[email-masked]> wrote:
    > You write: "My thermostat should not have to talk to a CA or remote
    > authentication server to read a new temperature sensor."  If you allow
    > everyone to read the temperature then that might be fine but you may
    > want to   

I just want to remind that "scaling" is often confused with "can grow really big".
when really, it means that a service/protocol/etc. can be sized for both
small and big deployments.

Certificate Authorities do not scale.  They are good for medium to very large
entities, but fail to accomodate the "small", and concern about this failure
is what people are reacting to. (It's not strictly a protocol problem, so
much as an implementation failure. There are significant market issues here
as well)

    > d) you may not want to use the same keying material forever (for many
    > reasons, including privacy, and performance). 

I actually think that this is perhaps the only useful concern.  And when you
write "rekeying", you actually need to think: "I just bought a house. I need
to change the keys".  Most people think about the meatspace keys, but we will
need to think about the other keys too.

    > Hence, there is the question why the thermostat shouldn't talk to a
    > trusted third party. That party might even be in your local network, or
    > in the same administrative domain (e.g., enterprise network); it does
    > not need to be in the "cloud".  

The question is: what is the market for this device.  Who is going to sell,
maintain, and profit from it?   While this is slightly outside the IETF
mandate, it is important to ask: are the people who are going to make that
device present in this BOF/WG list?  We ask that question before we begin
standardizing routing protocols....

    > Imagine if you have a version that uses symmetric cryptography and
    > another one that uses asymmetric cryptography. Obviously, a device
    > implementing the symmetric variant will not be able to talk to a device
    > that uses the asymmetric variant (unless that device implements both
    > variants).  

We do have some protocols (IKEv2 comes to mind) where the authentication in
each direction does not have to be the same.  While I know that TLS can forgo
client authentication, I'm unclear if it can authenticate using a different
mechanism than the server.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Paul Lambert <[email-masked]>
Date: Thu, 6 Feb 2014 15:24:03 -0800

> I think we should avoid statements like "Symmetric keys don't scale" since they are obviously wrong, as noted in the email further below.

Yes. My mistake not being very clear in the statement … as previously expanded … I will continue to try and clarify:

Symmetry keys do not scale for interesting use cases that should be considered.  Scaling is not just ‘size’ in terms of the number of devices within a single network.  Scaling should also consider the issues of many management entities (like in a home environment).  Symmetric keys used for authentication introduce considerable complexity when the authentication/identification/authorization must be shared between multiple systems.

> What you want to say is that you don't like some of the properties of symmetric keys for your use case, for example the use of a trusted third party. That's a completely different story. 

Yes. The properties of managing secrets as the primary means of authentication adds considerable complexity to complex environments where more than one system manages the identities and authorization.

For example … if we all use Facebook, there is a single management entity and all systems can use the password based (shared secret) authentication of the system for identification/authentication.

Where smaller devices or communities are possible that do not directly delegate identity to a single third party the use of public keys as the primary method of identification/authentication simplifies the overall architecture.  

> a) get a certificate (or symmetric key) at some point in time to the thermostat so that it can interact with the other devices, 
yes.,  devices must maintain a list of other trusted devices and what the devices are trusted to perform.  For a Thermostat it could be
 - read local temp: any
 - set temp: *alice   # where *alice would be the identity of the authorized peer

more likely groups would be used ...

> b) you might want to have a story for revoking the key, 
yes.
> c) you might also want to have access control policies configured that tell you which device is allowed to access which resources, 
yes.
> d) you may not want to use the same keying material forever (for many reasons, including privacy, and performance).
yes.

> 
> Hence, there is the question why the thermostat shouldn't talk to a trusted third party.
It might on occasion.  Real-time connectivity to a single TTP for the purposes of authentication or authorization is not acceptable for mobile environments (e.g. cell phones indoors talking to things)
One or more TTP is always required in use cases to support user convienent management

> That party might even be in your local network, or in the same administrative domain (e.g., enterprise network); it does not need to be in the "cloud”. 
Yes.  Likely it will be an application on one or more cell phones.
> Imagine if you have a version that uses symmetric cryptography and another one that uses asymmetric cryptography. Obviously, a device implementing the symmetric variant will not be able to talk to…

Yes … hence the reason I jumped in the discussion with the position that symmetric secret based identities should be avoided.  

Identity should be based on the demonstrated ownership of a public keys.

Paul

---

From: Paul Lambert <[email-masked]>
Date: Thu, 6 Feb 2014 15:28:09 -0800

> small and big deployments.

Yes!
> much as an implementation failure. There are significant market issues here

Yes, but ...
X.509 Certificate Authorities do not scale … for environments that need to support many naming domains and many possible types of authorization attributes.

The failure of X.509 Certificates to scale in a manner to support more complex naming and authorization models should not be a deterrent to the use of public keys for identity/authentication.

Do note that I’m advocating ‘public keys’ not ‘PKI’.

Paul

---

From: Likepeng <[email-masked]>
Date: Fri, 7 Feb 2014 07:57:46 +0000

> I do not see this specification in the open OMA documents - do you have a pointer?

Here it is:
http://technical.openmobilealliance.org/Technical/release_program/lightweightM2M_v1_0.aspx

The most relevant document is: OMA-TS-LightweightM2M-V1_0-20131210-C.pdf.

OMA LwM2M mainly defines the Access Control List data object, and the ACL data object defines which operations on a given resource are allowed for which requestor(s).

ACL data object is stored in the resource server, and it can be provisioned and changed afterwards.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Paul Lambert
> 发送时间: 2014年2月4日 2:10
> 收件人: Ludwig Seitz
> 抄送: [email-masked]
> 主题: Re: [Ace] New Version of Proposed Charter
> 
> 
> >>> tend to assume an always-on Internet connection to get to secret
> >>> based authentication servers.  Local symmetric key authentication is
> >>> APs).  This appears useful or small groups and home applications -
> >>> but adds the complexity of password based enrollment.  Alternatives
> >>> to password based enrollment (WPS2, WPS3, etc) start to use public
> >>> key exchanges to improve the user experience.  Simply starting with
> >>> architecture allowing better distributed/P2P interactions that are
> >>> not dependant on server or services.
> >>>
> More seriously - I’m only pointing out the mistake of continuing to mandate
> authentication systems based on shared secrets when we should be using
> public keys.  Any data schemas from OMA would be orthogonal.
> 
> >
> asymmetric crypto operations?
> Yes.
>

---

From: Likepeng <[email-masked]>
Date: Fri, 7 Feb 2014 08:15:41 +0000

Hello all,

Receiving no further feedback, I assume that people are fine with the proposed change for the task list item 4 in the charter V0.3?

Here is the proposed text:
Define a mechanism for authenticated and protected transfer of authorization information suitable for constrained environments, and taking into account expiry/revocation.

Thanks,
Kind Regards
Kepeng

发件人: 鹏程万里 [mailto:[email-masked]]
发送时间: 2014年1月24日 22:25
收件人: Göran Selander; Likepeng; [email-masked]
主题: Re: [Ace] New Version of Proposed Charter

>Define a mechanism for authenticated and protected transfer of
>authorization information suitable for constrained environments, and
>taking into account expiry/revocation.

Personally I am fine with that. Let's see if others have any opinion.

BTW: I am at home, and I use another email address.

Kepeng

------------------ Original ------------------
From:  "Göran Selander";<[email-masked]<mailto:[email-masked]>>;
Date:  Fri, Jan 24, 2014 07:03 PM
To:  "Likepeng"<[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>;
Subject:  Re: [Ace] New Version of Proposed Charter

On 24/01/14 10:27, "Likepeng" <[email-masked]<mailto:[email-masked]>> wrote:

>> I think the issues around authorisation lifetime or revocation deserves
>>should also be listed in the tasks below
>
>Currently we have this task in the list:
>€Define a mechanism for authenticated and protected transfer of
>authorization information suitable for constrained device to constrained
>device communication.
>
>Do you have any proposal to merge the lifetime/revocation into the
>sentence above?
>
>Or have another general task? If we have a separate bullet just for
>lifetime/revocation, that may be too emphasized.

How about:

Define a mechanism for authenticated and protected transfer of
authorization information suitable for constrained environments, and
taking into account expiry/revocation.

Too short?

Göran

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace
.

---

From: Likepeng <[email-masked]>
Date: Fri, 7 Feb 2014 08:23:47 +0000

Hello all,

The mail below is the latest message I can find about the task list item 3 in the charter:
http://www.ietf.org/mail-archive/web/ace/current/msg00167.html

Here is the proposed change:
Document design criteria for the required security protocols with respect to resource usage (RAM, message round trips, power consumption etc.).

If there are no further comments, I will incorporate this change in the next version of the charter.

Thanks,
Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 G?ran Selander
> 发送时间: 2014年1月28日 17:02
> 收件人: Stefanie Gerdes; [email-masked]
> Hi Steffi
> On 27/01/14 15:35, "Stefanie Gerdes" <[email-masked]> wrote:
> 
> >Hi Göran,
> >
> >On 01/27/2014 11:18 AM, Göran Selander wrote:
> >> Hi Kepeng
> >>
> >> On 27/01/14 10:31, "Likepeng" <[email-masked]> wrote:
> >>
> >>>>> Document the applicability of the main authentication and key
> >>>>>exchange  protocols with respect to resource usage (RAM, message
> >>>>>round trips,  power consumption etc.) and their suitability for the
> >>>>>use cases.
> >>>>
> >>>> 5. Referring to 3. above, it is in this context I see the need to
> >>>> specify design constraints, to be able to make a comparison and to
> >>>> decide what to standardise.
> >>>
> >>> According to the previous discussion, it seems that you propose to
> >>>change  this bullet to:
> >>>
> >>> Document design criteria for the required security protocols with
> >>>respect  to resource usage (RAM, message round trips, power
> >>>consumption etc.).
> >>
> >> Yes, that is a good summary.
> >
> >The task about the applicability of main authentication and key
> >exchange protocols was added to the list of tasks because we need to
> >make sure that we don't reinvent the wheel (open issue 3).
> >
> >I am not quite sure what you are aiming at with documenting the design
> >criteria. I can't really picture what a practical work item would be
> >for that task. Can you explain that in more detail?
> 
> I¹ll try :-)
> 
> I did not want to put ³document design criteria" against ³document
> applicability². In fact I think they are complementing each other: How do you
> determine ³applicability²?  For this you need an understanding and/or make
> certain assumptions of the various Œcosts' in constrained devices associated to
> certain security protocol constructions. The intention with ³document design
> criteria² is to describe some of these aspects. In this sense, deciding on
> relevant ³design criteria² is a pre-requisite to determine ³applicability².
> 
> The former may also be useful in comparing different constructions. As a
> concrete example, let¹s say that in one protocol you have reduced crypto in
> constrained device to a bare minimum, and in another protocol you instead
> reduce the number of round trips at the cost of performing a large amount of
> symmetric key crypto. Which protocol is preferred from the point of view of
> e.g. energy consumption in a wireless device?
> 
> In some cases this may be easy to state, in other cases this may depend on
> certain conditions and you need to make assumptions. Another objective of
> this task could be to document such assumptions. The practical work would be
> to put together this kind of information regarding "costs² in an informational
> document to be used as rationale when profiling an existing protocol or
> designing a new. I imagine this not so much new results as a compilation of
> knowledge in CoRE, LWIG, etc. set in the context of security protocols.
> 
> Does that make more sense?
> 
> Göran
>

---

From: Likepeng <[email-masked]>
Date: Fri, 7 Feb 2014 08:41:27 +0000

Hello all,

This is about our task list item 2 in the charter: Define profiles for certificates used for authenticated authorization.

We have two open issues: one is about the wording "authenticated authorization", another is about asymmetric key vs. symmetric key.

Previously Goran proposed to change it to:
Optimize existing and design new security modes for CoAP, e.g. profiles for X.509 certificates used in the CoAP/DTLS certificate security mode.

Any feedback about this? Or any new proposals?

Thanks,
Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Stefanie Gerdes
> 发送时间: 2014年1月29日 18:33
> 收件人: Bert Greevenbosch; Göran Selander; Olaf Bergmann
> 抄送: [email-masked]
> Hi Bert,
> On 01/29/2014 01:57 AM, Bert Greevenbosch wrote:
> > Having said that, I wonder whether the possible broad interpretation
> > of the sentence
> >
> > "Define profiles for certificates used for authenticated authorisation"
> >
> > is really that troublesome. The sentence does however assume a certificate
> based solution. That may be too early, as I could also imagine solutions with
> some pre-shared secrets between AS and Resource Server/Client, and
> everything built on that.
> 
> Yes, I think we should consider both symmetric and asymmetric solutions.
> There was some discussion about this in Vancouver but we didn't come to an
> agreement. We favor a symmetric solution in DCAF but other people seem to
> assume that asymmetric crypto is better suited.
> 
> Best regards,
> Steffi
>

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 07 Feb 2014 12:38:34 +0100

Hi,

Likepeng <[email-masked]> writes:

> This is about our task list item 2 in the charter: Define profiles for
> certificates used for authenticated authorization.
>
> We have two open issues: one is about the wording "authenticated
> authorization", another is about asymmetric key vs. symmetric key.

The main text now has some explanatory language how authorization relies
on authentication. Isn't this sufficient for an intuitive understanding
of that abbreviated term in the task list? I do not see any need to make
the task description unreadable by trying to define that term or provide
a longis description.

> Optimize existing and design new security modes for CoAP,
> e.g. profiles for X.509 certificates used in the CoAP/DTLS certificate
> security mode.

This is a very deep dive into solution space. In particular, I have
advoceted for not narrowing the focus specifically to X.509 usage with
CoAP/DTLS. Especially if the references to CoAP and DTLS would be
removed from the main charter text as Hannes has suggested.

We also had a discussion about the semantics of the term "design new
security modes" and found that although it has the intended meaning, it
is misleading because it looks like we wanted to change CoAP itself. The
same holds for "Otimize existing".

In my opinion, the existing text ("Define profiles for certificates used
for authenticated authorization.") perfectly describes the outstanding
task without suggesting a particular technical solution. (And I do not
think this rules out symmetric keys because it is just one task among
many others.)

Gruesse
Olaf

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 07 Feb 2014 12:56:40 +0100

Paul,

> Identity should be based on the demonstrated ownership of a public keys.

I think this is an important point in your arguing for public keys. You
want them as identifier used in authentication.

First of all, as was discussed before, we should take into consideration
that the devices' identities are given by a set of attributes. This may
be a set of just one element, including the public key as its value, in
some scenarios but this is not always the case. For example, a second
element in this list may be the device group identifier.

And, given that a device has some initial keying material (this is a
precondition for ace but how this happens is out of scope), I do not see
why there is any difference between symmetric and asymmetric keys
(except for the additional contribution to global warming of the latter
option.) -- I completely understand the business model for chip
manufacturers and equipment vendors behind using asymmetric keys. And I
understand why these are useful when certificates and PKIX are used. But
in a distributed environment without a central authentication and
authorization server, what is their benefit?

Gruesse
Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 07 Feb 2014 14:00:17 +0100

> think this rules out symmetric keys because it is just one task among

Certificates are very commonly associated with PKI, so this text does 
indeed suggest a specific technical solution, and I don't think it should.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Rene Struik <[email-masked]>
Date: Fri, 07 Feb 2014 11:08:11 -0500

Dear Olaf:

I have a quiz question for you all:

What is the estimated *total* energy cost of carrying out 30 billion elliptic curve scalar multiplications on RFID-style devices using a best-of-breed hardware only implementation. For simplicity, let us consider 163-bit binary curves. We will ignore any other aspects.

Answer options:
a) 1 kWh; {10c}
b) 1 thousand kWh;
c) 1 million kWh;
d) 1 billion kWh.

There are no prizes. However, I hope this puts the contribution that best-of-breed crypto computations make to global warming (vs. the contribution hereto of email traffic regarding the ACE charter and activities) into perspective.

Note: This question was triggered by Cisco's and Intel's forecast that by 2020 there would be 30 billion interconnected objects swarming the planet.

Best regards, Rene

[excerpt of your email as of February 7, 2014]
I do not see why there is any difference between symmetric and asymmetric keys (except for the additional contribution to global warming of the latter
option.)

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 07 Feb 2014 17:24:06 +0100

Rene,

Rene Struik <[email-masked]> writes:

> What is the estimated *total* energy cost of carrying out 30 billion
> elliptic curve scalar multiplications on RFID-style devices using a
> best-of-breed hardware only implementation. For simplicity, let us
> consider 163-bit binary curves. We will ignore any other aspects.

my apologies for the polemic remark. What I am more interested in is the
difference in battery lifetime for a single device.

Gruesse
Olaf

---

From: Rene Struik <[email-masked]>
Date: Fri, 07 Feb 2014 11:41:08 -0500

Hi Olaf:

In that case, the same quiz question still stands, but one now divides 
the answer by 30 billion.

I would encourage all to answer my computational energy consumption cost 
quiz question, but also answer the related quiz question re 
communication energy cost. For simplicity, let us consider an 802.15.4 
device, with power consumption of 10 mW and 250kbps raw data rate, where 
the listening time is 200 us and a single packet/frame is 128 bytes.

Once you do this homework exercise, you will get an idea of how to 
answer your question below.

Rene

[excerpt of your email below]

---

From: Likepeng <[email-masked]>
Date: Sat, 8 Feb 2014 03:03:14 +0000

Hi Ludwig,

>so this text does indeed suggest a specific technical solution, and I don't think it should.

Can you provide an alternative wording?

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Ludwig Seitz
发送时间: 2014年2月7日 21:00
收件人: [email-masked]
主题: Re: [Ace] New Version of Proposed Charter

On 02/07/2014 12:38 PM, Olaf Bergmann wrote:

>
> In my opinion, the existing text ("Define profiles for certificates 
> used for authenticated authorization.") perfectly describes the 
> outstanding task without suggesting a particular technical solution. 
> (And I do not think this rules out symmetric keys because it is just 
> one task among many others.)
>

Certificates are very commonly associated with PKI, so this text does indeed suggest a specific technical solution, and I don't think it should.

/Ludwig

--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Paul Lambert <[email-masked]>
Date: Sat, 8 Feb 2014 17:29:20 -0800

Yes.
> that the devices' identities are given by a set of attributes.
Perhaps … this is a view.  

Another model would be to consider that an ‘identity’ at it’s basis
is the set of information that can be cryptographically proven to be
owned by only the ‘speaking’ device.  This cryptographically 
should be a public key. 

Public keys may be then associated with attributes that might
include names, addresses, group membership, device 
descriptions etc.

Each type of attrbiute associated with a public key could have
have a different name space and trust hierarchy.  

So, this a is more key centric view where the public is the identity
and attributes may subsequently be assocaited with the identity.
The binding of attributes to a key might be by:
 - other keys signing a statement that assigns an attribute
   (e.g. a certificate like structure)
 - obtained from a trusted server 
 - obtained through a cryptographically authenticated tunnel
 - other out-of-band assignment

> This may
I’m arguing for the inverting your object hierarchy to start with the key.

> why there is any difference between symmetric and asymmetric keys
Huge difference.  In a truly distributed environment symmetric keys are
very hard to manage and distribute.

> (except for the additional contribution to global warming of the latter
No.  Public key cryptography should not be rejected for processing power.

> -- I completely understand the business model for chip
> manufacturers and equipment vendors behind using asymmetric keys.
?  

> And I
Public key authentication makes for simpler architectures and protocols.

Public keys do not need a central server …. not sure what yur point is here.

Paul

---

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 10 Feb 2014 01:00:54 +0000

Hi Paul, Olaf, all,

Thanks for the interesting discussion.

I agree, that if there was a public key, that public key could be used as an identity.

A public key infrastructure indeed may be achieved without a central server. PGP is a good example of such a de-centralised PKI.

Nevertheless, I think we should not forget that also in PGP there are third parties guaranteeing public keys, and thus the associated identities. So although PGP is de-centralised, it does not omit the need for a third party.

I just want to make sure we don't get into a trap thinking that the public key as an identity would be enough - we would have to do more. After all, anyone can generate a public key; without guarantee such public key / identity binding is useless.

Maybe a bit of an open door, but I just wanted to remind us of this. :-)

Best regards,
Bert

> -----Original Message-----
> From: Paul Lambert [mailto:[email-masked]]
> Sent: 09 February 2014 09:29
> To: Olaf Bergmann
> Cc: Stefanie Gerdes; Bert Greevenbosch; Hannes Tschofenig; [email-masked];
> Göran Selander
> Subject: Re: [Ace] Symmetric Keys Don't Scale ... was Aw: Re: New
> Version of Proposed Charter
> 
> 
> Perhaps . this is a view.
> 
> Another model would be to consider that an 'identity' at it's basis
> owned by only the 'speaking' device.  This cryptographically
> should be a public key.
> 
> I'm arguing for the inverting your object hierarchy to start with the
> key.
> 
> >
> Public keys do not need a central server .. not sure what yur point is
> here.
> 
> Paul
> 
> 
> >
> > Gruesse
> > Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 10 Feb 2014 08:48:33 +0100

> Can you provide an alternative wording?

How about "Define profiles for encoding authentication and authorization 
data"  ?

That way we don't only cover certificates, but also assertions, (OAuth) 
tokens, raw public keys, (Kerberos) tickets and whatever else could be 
profiled to restrict it to some compact representation.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: ma yc <[email-masked]>
Date: Mon, 10 Feb 2014 15:51:44 +0800

Support, the scope should not be restricted to certificates only.

Regards
Yuanchen

---

From: Ron Puzzle <[email-masked]>
Date: Mon, 10 Feb 2014 15:59:08 +0000

Hi Paul, Olaf, Bert and all

Please forgive my jumping in. 

I have similar considerations with Bert. The only public key used as identity may have some problems.

I agree that public key can make the user/devices/etc to make them distinguish with others. However, It would difficult to make the users/devices/etc. to be accepted by others. When Alice announce its public key to others, how they trust that is the right public key for Alice?

BRs,
Minpeng

---

From: Likepeng <[email-masked]>
Date: Wed, 12 Feb 2014 09:17:55 +0000

>How about "Define profiles for encoding authentication and authorization data"  ?

Fine with me.

Any other feedback?

Thanks,
Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Ludwig Seitz
发送时间: 2014年2月10日 8:49
收件人: [email-masked]
主题: Re: [Ace] New Version of Proposed Charter

> Can you provide an alternative wording?

How about "Define profiles for encoding authentication and authorization data"  ?

That way we don't only cover certificates, but also assertions, (OAuth) tokens, raw public keys, (Kerberos) tickets and whatever else could be profiled to restrict it to some compact representation.

/Ludwig

--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Paul Lambert <[email-masked]>
Date: Fri, 14 Feb 2014 09:57:48 -0800

> I just want to make sure we don't get into a trap thinking that the public key as an identity would be enough - we would have to do more. After all, anyone can generate a public key; without guaran…
No - not at all useless.  The whole point is that anyone / and device can and should create new identities (public keys).

Device setup always starts with public keys with no clear binding to other attributes (even in X.509).

As devices are introduced one to another, knowledge is learned in the introduction and local binding of info to key is created.   

As device create bindings of attributes to keys, this information can be shared with peers (e.g. signed attribute attestations)

SSH is an interesting worked example.  Widely used, no shared secrets to worry about for authentication. Very easy for small installations.  However, difficult to manage if many devices need common authorization/ACL management.   

> Maybe a bit of an open door, but I just wanted to remind us of this. :-)
Yes. Totally agree.  Public keys or hashes of public keys are a starting point … but any use case of interest eventually needs third party authorization/attestation. 

Multiple paths of architecture are possible:
 - raw key/hash ACLs
   useful starting point for many systems (e.g. SSH)
    - necessary starting point for bootstrapping devices without central authority
 - third party signatures
     - SDSI/SPKI -like, names rooted by speaking key (my preference -  can be modeled with FO logic)
        better semantics of constraints on attribute assignment would be significant improvement 
     - PGP like (no constraints or structure, flawed privacy )
     - single naming/issuing authorities (509) - bad solution since it does not readily support multi attribute authorities
      and not well suited for mixing with key centric authorization 
 - server / oracle based 
    - poll one or more servers for authorization info indexed by key hash
    - authorization could also be based on other attributes associated with key
 - tunnel based
    - effectively similar as above, but more appropriate for P2P systems
      trust in authorization is based on source auth bound to channel not signature
 - combinations of the above

Paul