Subject: [Ace] Open Issues

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 16 Jan 2014 16:27:08 +0100

Hi everybody,

We have a lot of topics and proposed charter changes right now. To speed
things up a little, I would like to summarize the main open issues. I
hope that will make it easier to find consent about them and helps us to
decide which topics should be in the scope of ACE.

Of course it is difficult to decide what the main issues are. I tried to
filter out topics concerning the comprehensibility at this point. We can
get back to them later when we the general scope is clear. If I left out
a very important topic please feel free to state your opinion (and maybe
explain why you think this is significant for the scope of ACE)

1. No pre-provisioned keys. There was some discussion about the case
where there is no pre-provisioned secret on the constrained device. Is
this in the scope of ACE? I had the impression that more people think
that it isn't?

2. Offline authorization
(http://www.ietf.org/mail-archive/web/ace/current/msg00105.html). Does
ACE want to cover the problem that a resource server might need to
process requests without consulting some kind of identity management server?

3. Profiling existing authentication, authorization and key management
protocols
(http://www.ietf.org/mail-archive/web/ace/current/msg00105.html).  a) Is
it in the scope of ACE to profile protocols like Kerberos, OAuth etc. b)
to which of the various steps during authorization (i.e.
device<->identity manager, identity manager<->resource server, ...) do
these profiles/protocols apply?

4. Security modes for CoAP
(http://www.ietf.org/mail-archive/web/ace/current/msg00104.html). Is it
in the scope of ACE to define security modes for CoAP?

Please state your opinion on these topics.

Best regards,
Steffi

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 16 Jan 2014 16:47:53 +0100

> this in the scope of ACE? I had the impression that more people think

I think this is out of scope.

> process requests without consulting some kind of identity management server?

Yes this is exactly what we want to cover. That's why we are planning to 
work on token formats in the solutions. Otherwise the resource server 
needs to manage two connections at the same time (one with the client 
and one with the IAM server), that doesn't seem realistic for many devices.

Do people think this should go into the charter though (it might also be 
a result of the design criteria work)?

> (http://www.ietf.org/mail-archive/web/ace/current/msg00105.html).

> a) Is it in the scope of ACE to profile protocols like Kerberos, OAuth etc.

We should at least look at them and clearly state why we are inventing 
something different if we do.

b)
> these profiles/protocols apply?

All steps directly involving at least one constrained device. I'm not 
interested in standardizing what the AS internally uses to make access 
control decisions for example, but if the client is constrained, the 
communication between AS and Client must be part of the standard.

> in the scope of ACE to define security modes for CoAP?

I'm obviously biased here, since it's the title of my draft. My main 
argument for including this is that the security modes are the first 
authorization step. What you do is to authorize the client to establish 
a DTLS connection in the first place.

tl;dr  1.) Not in scope, 2.) In scope, 3.) Might be 4.) In scope.

Regards,

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: Corinna Schmitt <[email-masked]>
Date: Thu, 16 Jan 2014 17:06:46 +0100

HAllo Ludwig,

good argumentation.
I agree with your points.

Regards,
Corinna

Am 16.01.14 16:47, schrieb Ludwig Seitz:
> Yes this is exactly what we want to cover. That's why we are planning 
> to work on token formats in the solutions. Otherwise the resource 
> server needs to manage two connections at the same time (one with the 
> client and one with the IAM server), that doesn't seem realistic for 
> many devices.
>
> Do people think this should go into the charter though (it might also 
> be a result of the design criteria work)?
>
> authorization step. What you do is to authorize the client to 
> establish a DTLS connection in the first place.
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

--

---

From: Göran Selander <[email-masked]>
Date: Thu, 16 Jan 2014 16:24:09 +0000

Hi Steffi

Comments inline.

>this in the scope of ACE? I had the impression that more people think

Correct, main case is shared keys *between resource server and
authorization server*, e.g. secret key of authorization server provisioned
to resource server. However, there need not be any a priori shared keys
between client and resource server.

>process requests without consulting some kind of identity management

I think there may be a misunderstanding or unclear formulation (?). Do you
mean "without consulting some kind of identity management server" *at all*
or "without consulting some kind of identity management server" *as part
of the resource request response procedure*. I think "offline" refers to
the case that the resource server is not assumed to be able (for reasons
of its constrained nature) to contact the authorization server for an
authorization decision. This case is clearly covered in the proposed
solutions and should be in scope.

>these profiles/protocols apply?

I think it is in scope of ACE of not re-inventing the wheel :-) Having
said that it is clear that none of these protocols are optimized for
constrained environments. And I believe it is not necessary to redesign an
existing protocols for a task which it was not designed for, whatever the
cost, just because the protocol exists. However in the case of OAuth,
which is addressing a similar problem space, we should ensure that we
don't prevent its use in some parts e.g. in acquisition of access token if
the client is non-constrained, token formats, etc.; whereas other parts,
e.g. the protocol between client and resource server may potentially need
to be different compared to OAuth.

>in the scope of ACE to define security modes for CoAP?

I am also biased when I say that this should be in scope. But this is not
only about the "security modes" draft, the work item on "profiles for
certificates" in the current charter draft (contributed by someone else),
is also work on improving CoAP security modes.

Best regards,
Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 16 Jan 2014 17:48:08 +0100

Hi Ludwig,

> a DTLS connection in the first place.

I think it is interesting to think about the various possible solutions
for authenticating the authorization information such as symmetric and
asymmetric key approaches or even object security. I am not sure,
however, if we need new security modes for CoAP for that. Don't we just
need to define how we use the existing ones?

Best regards,
Steffi

---

From: Bert Greevenbosch <[email-masked]>
Date: Fri, 17 Jan 2014 05:42:44 +0000

Hi all,

> this in the scope of ACE? I had the impression that more people think

That may be difficult. In principle, you need at least something pre-provisioned to setup a secure connection, although it may not necessarily be secret (e.g. a public key of the trusted 3rd party).

I think the pre-provisioning method of the initial cryptographic parameters can be left out of scope though. Having a scenario without any pre-provisioned key should be out of scope.

> process requests without consulting some kind of identity management

I think this is a reality. There could be scenarios where the server is too constrained to contact the trusted 3d party by itself. There could e.g. be scenarios where such information from the trusted 3rd party is forwarded by the client to the server.

> these profiles/protocols apply?

I think we should reuse existing technologies where appropriate, as it is always good to use security mechanisms which already have proven their value. This may include profiling. So this is in scope.

>From the security modes draft, I have the impression that it mainly concerns key management (KMS). Is that impression correct?

Concerning the KMS, I think we should certainly investigate existing technologies as elaborated upon below comment 3.

I think it will be hard to define a working system without paying attention to the KMS.

Best regards,
Bert

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Stefanie Gerdes
> Sent: 16 January 2014 23:27
> To: [email-masked]
> Subject: [Ace] Open Issues
> 
> Hi everybody,
>

---

From: Göran Selander <[email-masked]>
Date: Fri, 17 Jan 2014 08:05:07 +0000

Hi Bert

On 1/17/14 6:42 AM, "Bert Greevenbosch" <[email-masked]>
wrote:
>From the security modes draft, I have the impression that it mainly
>concerns key management (KMS). Is that impression correct?
>
>Concerning the KMS, I think we should certainly investigate existing
>technologies as elaborated upon below comment 3.
>

You are right, this is about key management. CoAP security modes in
general deals with what keys/credentials of involved parties that are
required to be able to authorize the client to run DTLS. E.g. in
certificate mode the client must have a X509 public key certificate and
corresponding private key and the server must have a list of root trust
anchors that can be used for validating certificates. Since certificate
mode is very heavy-weight, we investigate in
draft-seitz-core-security-modes more light-weight solutions based on the
assumption that there is a secret key shared between an authorization
server (acting trust anchor) and a resource server.

Göran

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 17 Jan 2014 09:18:20 +0100

> need to define how we use the existing ones?

Well in the introduction of my draft I argue why I don't think the 
existing security modes are sufficient.

/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: Carsten Bormann <[email-masked]>
Date: Fri, 17 Jan 2014 09:48:36 +0100

> need to define how we use the existing ones?

I think that’s mostly a matter of “semantics” (understanding of terms).

Some people read the section 9 about security modes in the CoAP spec and derive a very literal understanding of what these security modes are.  Some others read them as building blocks.  The first group would think they are defining new security modes when the second group thinks they are applying the existing security modes in scenarios that are more complex than those used to explain the modes in the spec.

There is, of course, a big difference between NoSec and the other modes.  What the other modes materially differ in is what TLS cipher suite was used to set up the DTLS connection and what the keying materials used for setting them up can be used for.  The two PK modes (RPK and cert) also have a key that can be used as an identity of the server (the text doesn’t discuss whether you have to use the same kind in both directions or you have to use a client key at all).  Since a device can have multiple such identities, CoAP suggests using SNI, so a device with multiple public keys also needs a hostname-like name (or anything that can be put in a RFC 6066 ServerName).  The CoAP modes do not say what the authorization implication of these keys/identities are or how they are used in an authorization protocol. draft-seitz-core-security-modes adds some ways to use them and calls them additional CoAP modes.  This terminology may confuse some who think we are extending TLS with fundamentally new cipher suites.  It may also be more useful to define the entire authorization protocol instead of just the “CoAP mode” aspect of it.

Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 20 Jan 2014 16:09:03 +0100

On 01/17/2014 09:48 AM, Carsten Bormann wrote:
> Some people read the section 9 about security modes in the CoAP spec and
> derive a very literal understanding of what these security modes are.
 > Some others read them as building blocks.  The first group would think
 > they are defining new security modes when the second group thinks they
 > are applying the existing security modes in scenarios that are more
 > complex than those used to explain the modes in the spec.
>[...] draft-seitz-core-security-modes adds some ways to use them and
 > calls them additional CoAP modes.  This terminology may confuse some
 > who think we are extending TLS with fundamentally new cipher suites.
 > It may also be more useful to define the entire authorization protocol
 > instead of just the “CoAP mode” aspect of it.

Carsten, I am fine renaming the draft to something like "usage profile 
for CoAP security modes" if you think that can help to avoid confusion. 
The bigger question is: Is this work that people consider useful within 
ACE (I'm obviously biased here)?

I'm also all in favour of defining the entire authorization protocol, 
but the question is: do we want to cram everything into one draft?

The advantage I see with having draft-seitz-core-security-modes separate
is that it allows you to implement a very coarse grain access control 
(at the level of "who can initiate a DTLS connection with this 
device?"). I suspect this would be enough for a relevant number of 
applications, that don't need to implement more sophisticated access 
control.

/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: Likepeng <[email-masked]>
Date: Thu, 23 Jan 2014 11:05:24 +0000

Hello all,

If I try to summarize the discussion so far, here is what I get:

1. Out of scope.
2. In scope.
3. Maybe.
4. Maybe.

I think we still need more discussion about issue 3 and 4.

Do I miss anything?

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Stefanie Gerdes
> 发送时间: 2014年1月16日 23:27
> 收件人: [email-masked]
> 主题: [Ace] Open Issues
> 
> Hi everybody,
> 
> things up a little, I would like to summarize the main open issues. I hope that
> will make it easier to find consent about them and helps us to decide which
> topics should be in the scope of ACE.
> 
> Of course it is difficult to decide what the main issues are. I tried to filter out
> topics concerning the comprehensibility at this point. We can get back to them
> later when we the general scope is clear. If I left out a very important topic
> please feel free to state your opinion (and maybe explain why you think this is
> significant for the scope of ACE)
> 
> 1. No pre-provisioned keys. There was some discussion about the case where
> there is no pre-provisioned secret on the constrained device. Is this in the
> scope of ACE? I had the impression that more people think that it isn't?
> 
> 2. Offline authorization
> ACE want to cover the problem that a resource server might need to process
> requests without consulting some kind of identity management server?
> 
> (http://www.ietf.org/mail-archive/web/ace/current/msg00105.html).  a) Is it
> in the scope of ACE to profile protocols like Kerberos, OAuth etc. b) to which of
> the various steps during authorization (i.e.
> device<->identity manager, identity manager<->resource server, ...) do these
> profiles/protocols apply?
> 
> (http://www.ietf.org/mail-archive/web/ace/current/msg00104.html). Is it in
> the scope of ACE to define security modes for CoAP?
>