Subject: [Ace] ACE Charter Proposal v0.6

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Mar 2014 02:25:08 +0100

--> Here is an update based on comments from Goeran.

Draft Charter V0.6 - Authentication and Authorization for Constrained
Environment (ACE)

The IETF has recently developed protocols for use in environments where
network nodes are limited in CPU, memory, and power. It was observed
that Internet protocols can be applied to these constrained
environments, often only requiring minor tweaking and profiling. In
other cases, new protocols have been defined to address the specific
requirements of constrained devices and networks. An example of such a
protocol is the Constrained Application Protocol (CoAP).

As in other environments, authentication and authorization question also
arise in environments with constrained nodes and networks. For example,
a door lock has to authorize the person seeking access using a "digital
key". Where are the authorization decisions stored? How does the digital
key communicate with the lock? Does the lock interact with an
authorization server to obtain authorization information? How can access
be granted to other persons temporarily? How can access be revoked?
These types of questions have been answered by existing protocols for
use cases outside the constrained environment. But in constrained
environment, additional requirements pose challenges for the use of
various security protocols. In particular, the need for a dynamic and
fine grained access control mechanism whereby clients and/or resource
servers suffer from constraints arises.

The IETF has a long history in developing three party authentication and
authorization protocols for distributed environments. Examples include
Kerberos, the Public Key Infrastructure (PKI), the Authentication,
Authorization, and Accounting (AAA) infrastructure, and the Web
Authorization Protocol (OAuth). All these protocols enjoy widespread
deployment on the Internet. Although they all aim to solve a similar
goal, at an abstract level, they offer quite different functions and
utilize different message exchanges. These differences are motivated by
the main deployment use cases they were designed for.

Requirements derived from use cases indicate the suitability of already
existing work, such as OAuth, as a solution for constrained
environments. These protocols were, however, not optimized for
constrained environments. Additional requirements that need to be taken
into account are the lack of a suitable user-interface for obtaining the
consent of the user and the inability of embedded devices to contact an
authorization server in real-time with every access request due to
intermittent connectivity, etc.

This working group therefore aims for a standardized solution for
authentication and authorization to enable authorized access to
resources in constrained environments. As a starting point, the working
group will assume that access to resources offered by a resource server
by a client devices takes place using CoAP and is protected by DTLS.
Both resource server and client may be resource constraint. This access
will be mediated by an authorization server, which does not suffer from
the same resource limitations.

Existing authentication and authorization protocols are used and
re-applied for use with constrained devices, where applicable. This
requires relevant specifications to be reviewed for suitability,
selecting a subset of them, restricting the options within each of the
specifications. Some functionalities may, however, not be available in
existing protocols and for those cases new functionality has to be
standardized. Thus, existing work can be leveraged and the group
benefits from available security analysis, implementation, and
deployment experience. Moreover, a standardized solution for federated
authentication and authorization will help to stimulate the deployment
of IoT devices offering increased security.

Once progress in identifying suitable candidate solutions has been made
the working group will verify whether the same mechanism are also
applicable beyond the use of CoAP and DTLS, which are the two main
protocols the group will focus on for access to resources. In
particular, the ability to use the developed solution over HTTP and TLS
will be investigated. Furthermore, to guarantee smooth transition the
integration with existing deployment will be studied. This particularly
concerns the use of protocol translation proxies.

To be successful this working group requires expertise in security,
privacy, and a good understanding of usability in the constrained
environment space. This work does not make the assumption that the party
offering application layer services is always the same party offering
network access services.

The working group has the following tasks (in this order):

1) Use cases, requirements, and design criteria.
[[Details pending mailing list discussion.]]
This work will guide the identification of suitable protocol mechanisms.

2) Selection of an authentication and authorization protocol for
constrained environments.

3) Evaluation of the candidate solution for use with HTTP/TLS and proxy
deployments.
[[Details pending mailing list discussion.]]

---

From: Likepeng <[email-masked]>
Date: Mon, 17 Mar 2014 07:34:31 +0000

I updated our wiki page according to Hannes' charter proposal:
http://trac.tools.ietf.org/wg/core/trac/wiki/ACE_charter#

The changes are highlighted in bold font.

Please review it and provide your feedback.

Thanks,

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Hannes Tschofenig
> 发送时间: 2014年3月13日 9:25
> 收件人: [email-masked]
> 主题: [Ace] ACE Charter Proposal v0.6
> 
> network nodes are limited in CPU, memory, and power. It was observed that
> Internet protocols can be applied to these constrained environments, often
> only requiring minor tweaking and profiling. In other cases, new protocols
> have been defined to address the specific requirements of constrained devices
> and networks. An example of such a protocol is the Constrained Application
> Protocol (CoAP).
> 
> As in other environments, authentication and authorization question also arise
> in environments with constrained nodes and networks. For example, a door
> lock has to authorize the person seeking access using a "digital key". Where are
> the authorization decisions stored? How does the digital key communicate
> with the lock? Does the lock interact with an authorization server to obtain
> authorization information? How can access be granted to other persons
> temporarily? How can access be revoked?
> These types of questions have been answered by existing protocols for use
> cases outside the constrained environment. But in constrained environment,
> additional requirements pose challenges for the use of various security
> protocols. In particular, the need for a dynamic and fine grained access control
> mechanism whereby clients and/or resource servers suffer from constraints
> arises.
> 
> deployment on the Internet. Although they all aim to solve a similar goal, at an
> abstract level, they offer quite different functions and utilize different message
> exchanges. These differences are motivated by the main deployment use cases
> they were designed for.
> 
> Requirements derived from use cases indicate the suitability of already existing
> work, such as OAuth, as a solution for constrained environments. These
> protocols were, however, not optimized for constrained environments.
> Additional requirements that need to be taken into account are the lack of a
> suitable user-interface for obtaining the consent of the user and the inability
> of embedded devices to contact an authorization server in real-time with every
> access request due to intermittent connectivity, etc.
> 
> authentication and authorization to enable authorized access to resources in
> constrained environments. As a starting point, the working group will assume
> that access to resources offered by a resource server by a client devices takes
> place using CoAP and is protected by DTLS.
> Both resource server and client may be resource constraint. This access will be
> mediated by an authorization server, which does not suffer from the same
> resource limitations.
> 
> Existing authentication and authorization protocols are used and re-applied
> for use with constrained devices, where applicable. This requires relevant
> specifications to be reviewed for suitability, selecting a subset of them,
> restricting the options within each of the specifications. Some functionalities
> may, however, not be available in existing protocols and for those cases new
> functionality has to be standardized. Thus, existing work can be leveraged and
> the group benefits from available security analysis, implementation, and
> authentication and authorization will help to stimulate the deployment of IoT
> devices offering increased security.
> 
> Once progress in identifying suitable candidate solutions has been made the
> working group will verify whether the same mechanism are also applicable
> beyond the use of CoAP and DTLS, which are the two main protocols the group
> will focus on for access to resources. In particular, the ability to use the
> developed solution over HTTP and TLS will be investigated. Furthermore, to
> guarantee smooth transition the integration with existing deployment will be
> studied. This particularly concerns the use of protocol translation proxies.
> 
> To be successful this working group requires expertise in security, privacy, and
> a good understanding of usability in the constrained environment space. This
> work does not make the assumption that the party offering application layer
> services is always the same party offering network access services.
> 
> [[Details pending mailing list discussion.]] This work will guide the
> identification of suitable protocol mechanisms.
> 
> 2) Selection of an authentication and authorization protocol for constrained
> environments.
>

---

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 17 Mar 2014 09:30:52 +0000

I have reviewed the new charter.

I have a comment on the following task:
> 2) Selection of an authentication and authorization protocol for constrained environments.

I think there is more to it than "selection", especially since we may need to make some adjustments or define something new for the constrained case.

So I support Göran's proposal to change the task, but I propose a slightly different version:

> 2) Identify suitable authentication and authorization mechanisms, in particular addressing dynamic and fine grained access control suitable for CoAP resource access requests in constrained environments.

What do you think?

Best regards,
Bert

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: 13 March 2014 09:25
> To: [email-masked]
> Subject: [Ace] ACE Charter Proposal v0.6
> 
> As in other environments, authentication and authorization question
> also arise in environments with constrained nodes and networks. For
> example, a door lock has to authorize the person seeking access using a
> "digital key". Where are the authorization decisions stored? How does
> the digital key communicate with the lock? Does the lock interact with
> an authorization server to obtain authorization information? How can
> access be granted to other persons temporarily? How can access be
> revoked?
> The IETF has a long history in developing three party authentication
> and authorization protocols for distributed environments. Examples
> include Kerberos, the Public Key Infrastructure (PKI), the
> Authentication, Authorization, and Accounting (AAA) infrastructure, and
> the Web Authorization Protocol (OAuth). All these protocols enjoy
> widespread deployment on the Internet. Although they all aim to solve a
> similar goal, at an abstract level, they offer quite different
> functions and utilize different message exchanges. These differences
> are motivated by the main deployment use cases they were designed for.
> 
> into account are the lack of a suitable user-interface for obtaining
> the consent of the user and the inability of embedded devices to
> contact an authorization server in real-time with every access request
> due to intermittent connectivity, etc.
> 
> Existing authentication and authorization protocols are used and re-
> applied for use with constrained devices, where applicable. This
> environment space. This work does not make the assumption that the
> party offering application layer services is always the same party
> offering network access services.
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 17 Mar 2014 11:23:28 +0100

> I think there is more to it than "selection", especially since we may need to make some adjustments or define something new for the constrained case.

Indeed.

>> 2) Identify suitable authentication and authorization mechanisms, in particular addressing dynamic and fine grained access control suitable for CoAP resource access requests in constrained environ…

We can try to weasel around this, but if this group is successful, the result will be the definition of certain new protocol components.
Reusing existing mechanisms, (abstract) protocols, or even encodings as much as possible is desirable, but there also is an objective to be met here.
This is not possible by stitching together a Frankenprotocol (which, by composing old elements in a new way, still would be a new protocol).

Grüße, Carsten

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 17 Mar 2014 09:21:05 -0400

Hi Carsten,

>> I think there is more to it than "selection", especially since we may need to make some adjustments or define something new for the constrained case.

I agree with this, too.  I think the charter should be open to profiling, adjusting or extending existing security mechanisms to meet the needs of this environment.

>>> 2) Identify suitable authentication and authorization mechanisms, in particular addressing dynamic and fine grained access control suitable for CoAP resource access requests in constrained enviro…

I think this goes too far into the requirements space…  I think we are planning to define the requirements and architecture as part of the charter, and I think that one area that needs a lot of discussion is what our requirements are for access control, and what roles the RS and AS will play in that.  For instance, we might decide that we want an attribute or role-based system where the authentication process returns various attributes and/or roles associated with the authenticated user, and that information is used by the RS to determine what access should be allowed.  In that case, the granularity of the access control could be application-specific and would be a matter of AS configuration and local implementation on the RS.

I want our charter to lean _strongly_ in the direction of preferring a solution that is based on existing security protocol standards, unless/until we can determine that none of them can meet the requirements, even with appropriate profiles, extensions or modifications.  I think that is pretty unlikely based on the breadth and variety of existing security protocols.  I think we should require a recharter to undertake development of a new security protocol.

So, I would propose something like this:

2) Selection of an existing authentication and authorization protocol that can serve as the basis of an authentication and authorization system for  constrained environments.  

3) Definition of whatever profiles, extensions or modifications are required to make the selected authentication and authorization protocol suitable for constrained environments.

> This is not possible by stitching together a Frankenprotocol (which, by composing old elements in a new way, still would be a new protocol).

Depending on what you mean here, I might or might not agree…

For instance, if we decide that an EAP-based approach could work in this environment (as it does for every wi-fi device that needs to join an 802.11x-secured network), I think we might want to define an EAP method that leverages the existing crypto algorithms and security protocols available on the constrained device, based on the assumption that the device will also implement a constrained version of DTLS (as defined by the DICE WG).  Where would that fall in your view of the world?  I don't think it would be a Frankenprotocol at all, since EAP is designed to be extended that way.  There also wouldn't be much new protocol work, as an EAP-DTLS method could be pretty similar to the existing EAP-TLS method.  Assuming something like that could meet our as-yet-undetermined requirements for this environment, would you consider that to be a successful outcome?

Margaret

---

From: Göran Selander <[email-masked]>
Date: Mon, 17 Mar 2014 17:10:07 +0000

Hi Margret,

On 17/03/14 14:21, "Margaret Wasserman" <[email-masked]> wrote:

>>> I think there is more to it than "selection", especially since we may
>>>need to make some adjustments or define something new for the
>>>constrained case.
>> 
>> Indeed.
>
>I agree with this, too.  I think the charter should be open to profiling,
>adjusting or extending existing security mechanisms to meet the needs of
>this environment.
>
>>>> 2) Identify suitable authentication and authorization mechanisms, in
>>>>particular addressing dynamic and fine grained access control suitable
>>>>for CoAP resource access requests in constrained environments.
>>> 
>>> What do you think?
>
>I think this goes too far into the requirements spaceŠ  I think we are
>planning to define the requirements and architecture as part of the
>charter, and I think that one area that needs a lot of discussion is what
>our requirements are for access control, and what roles the RS and AS
>will play in that.  For instance, we might decide that we want an
>attribute or role-based system where the authentication process returns
>various attributes and/or roles associated with the authenticated user,
>and that information is used by the RS to determine what access should be
>allowed.  In that case, the granularity of the access control could be
>application-specific and would be a matter of AS configuration and local
>implementation on the RS.

I can see where you are coming from. The ³in particular addressing dynamic
and fine grained access control . . .² is a conclusion from the use case
and requirements draft. A better formulation would maybe have been  ³in
particular *allowing* dynamic and fine grained access control . . .² The
intent was not that all applications must have ³fine granular² access
policies, but that some applications require this so the solution must
support it.

We may completely disregard the previous work and redo the exercise, but I
believe that the support for dynamical changes of a client's rights and
application-specific granularity will remain a conclusion.

Forgetting for a moment that this is a preliminary conclusion, do you
still see a contradiction with this text and a solution based on an
attribute/role-based system where say the AS associated a client with
attributes/roles for the RS to match with locally specified rights?

>
>I want our charter to lean _strongly_ in the direction of preferring a
>solution that is based on existing security protocol standards,
>unless/until we can determine that none of them can meet the
>requirements, even with appropriate profiles, extensions or
>modifications.  I think that is pretty unlikely based on the breadth and
>variety of existing security protocols.  I think we should require a
>recharter to undertake development of a new security protocol.
>
>2) Selection of an existing authentication and authorization protocol
>that can serve as the basis of an authentication and authorization system
>for  constrained environments.
>
>3) Definition of whatever profiles, extensions or modifications are
>required to make the selected authentication and authorization protocol
>suitable for constrained environments.

While I certainly support the use an existing security protocol standard,
if feasible, I think that the process indicated here has a weakness: In
order to in step 2) assess that the selected protocol can serve as a basis
for constrained environments, a large part of the profiling and
modifications of step 3) must have already been performed.

Göran

>
>> We can try to weasel around this, but if this group is successful, the
>>result will be the definition of certain new protocol components.
>> Reusing existing mechanisms, (abstract) protocols, or even encodings as
>>much as possible is desirable, but there also is an objective to be met
>>here.
>> This is not possible by stitching together a Frankenprotocol (which, by
>>composing old elements in a new way, still would be a new protocol).
>
>Depending on what you mean here, I might or might not agreeŠ
>
>For instance, if we decide that an EAP-based approach could work in this
>environment (as it does for every wi-fi device that needs to join an
>802.11x-secured network), I think we might want to define an EAP method
>that leverages the existing crypto algorithms and security protocols
>available on the constrained device, based on the assumption that the
>device will also implement a constrained version of DTLS (as defined by
>the DICE WG).  Where would that fall in your view of the world?  I don't
>think it would be a Frankenprotocol at all, since EAP is designed to be
>extended that way.  There also wouldn't be much new protocol work, as an
>EAP-DTLS method could be pretty similar to the existing EAP-TLS method.
>Assuming something like that could meet our as-yet-undetermined
>requirements for this environment, would you consider that to be a
>successful outcome?
>
>Margaret
>
>
>
>
>_______________________________________________
>Ace mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ace

---

From: Robert Cragie <[email-masked]>
Date: Mon, 17 Mar 2014 19:59:44 +0000

Regarding the point on EAP-TLS: It is unlikely we would need an EAP-DTLS 
as DTLS is an adaptation of TLS to work over datagrams. Similarly, 
EAP-TLS (and EAP-TTLS) adapt TLS for use with EAP, which itself is a 
datagram protocol and provides lock-step Request-Response and 
fragmentation and reassembly support, like DTLS.

What may be important for constrained devices (and may be more of a 
topic for LWIG) would be the ability to have a single TLS base for 
handshake and record layers with a small set of common cipher suites 
which could be reused across TLS, DTLS and EAP-TLS implementations.

Robert

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 18 Mar 2014 14:24:30 +0100

Hi Margaret, all

> For instance, if we decide that an EAP-based approach could work in this environment

As part of a research activity here at the University of Murcia, we created an initial design of an authentication service based on EAP for CoAP sometime ago. In other words, CoAP messages are used to transport EAP between the CoAP client (EAP authenticator) and the CoAP server (EAP peer/ the constrained node). In particular, the EAP messages are directly transported in the CoAP message payload for this authentication service.  In this case, the EAP authenticator (CoAP client) can contact an external AAA server (which is one of the posible choices in ACE, as far as I have read). 

Once EAP has finished, we bootstrap a security association between CoAP server and CoAP client based on the MSK. In our case, this security association might be based on DTLS or by using a new AUTH option we have defined to be included in any CoAP message (no need of DTLS in the second case).

We have restarted the work some months ago and we have now a very limited proof-of-concept with libcoap. It is still in PC platform but we have started to build the implementation in COOJA simulator (without DTLS so far). Nevertheless, our intention is also to test it with DTLS.

I guess this could be also categorized as an EAP-based approach, though we do not know if it will be interesting for ACE members. If people think it is, we can prepare a short I-D explaining what we have until now.

> (as it does for every wi-fi device that needs to join an 802.11x-secured network), I think we might want to define an EAP method that leverages the existing crypto algorithms and security protocols available on the constrained device, based on the assumption that the device will also implement a constrained version of DTLS (as defined by the DICE WG).

In our case we have tested EAP-PSK since it uses AES-based cryptography. In fact, we have previous experience on that in real constrained devices (PANATIKI: A Network Access Control Implementation Based on PANA for IoT Devices http://www.mdpi.com/1424-8220/13/11/14888). But I agree that if we assume DTLS we may assume that an EAP-TLS method would be reasonable. Nevertheless, I agree with Robert that we may not need to design a new EAP method for that.

Just my 0.02 cents.

>  Where would that fall in your view of the world?  I don't think it would be a Frankenprotocol at all, since EAP is designed to be extended that way.  There also wouldn't be much new protocol work, as an EAP-DTLS method could be pretty similar to the existing EAP-TLS method.  Assuming something like that could meet our as-yet-undetermined requirements for this environment, would you consider that to be a successful outcome?
> 
> Margaret
> 
> 
> 
> 

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Likepeng <[email-masked]>
Date: Wed, 19 Mar 2014 03:19:27 +0000

> As part of a research activity here at the University of Murcia, we created an
> initial design of an authentication service based on EAP for CoAP sometime
> ago.

It is very good to see early implementations in this space.

> I guess this could be also categorized as an EAP-based approach, though we do
> not know if it will be interesting for ACE members. If people think it is, we can
> prepare a short I-D explaining what we have until now.

Sure, I-D is always welcome. It is beneficial to our work.

Thanks,

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Rafa Marin Lopez
> 发送时间: 2014年3月18日 21:25
> 收件人: [email-masked]
> 主题: Re: [Ace] ACE Charter Proposal v0.6
> 
> Hi Margaret, all
> 
> As part of a research activity here at the University of Murcia, we created an
> initial design of an authentication service based on EAP for CoAP sometime
> ago. In other words, CoAP messages are used to transport EAP between the
> CoAP client (EAP authenticator) and the CoAP server (EAP peer/ the
> constrained node). In particular, the EAP messages are directly transported in
> the CoAP message payload for this authentication service.  In this case, the
> EAP authenticator (CoAP client) can contact an external AAA server (which is
> one of the posible choices in ACE, as far as I have read).
> 
> Once EAP has finished, we bootstrap a security association between CoAP
> server and CoAP client based on the MSK. In our case, this security association
> might be based on DTLS or by using a new AUTH option we have defined to be
> included in any CoAP message (no need of DTLS in the second case).
> 
> We have restarted the work some months ago and we have now a very limited
> proof-of-concept with libcoap. It is still in PC platform but we have started to
> build the implementation in COOJA simulator (without DTLS so far).
> Nevertheless, our intention is also to test it with DTLS.
> 
> I guess this could be also categorized as an EAP-based approach, though we do
> not know if it will be interesting for ACE members. If people think it is, we can
> prepare a short I-D explaining what we have until now.
> 
> > (as it does for every wi-fi device that needs to join an 802.11x-secured
> network), I think we might want to define an EAP method that leverages the
> existing crypto algorithms and security protocols available on the constrained
> device, based on the assumption that the device will also implement a
> constrained version of DTLS (as defined by the DICE WG).
> 
> In our case we have tested EAP-PSK since it uses AES-based cryptography. In
> fact, we have previous experience on that in real constrained devices
> (PANATIKI: A Network Access Control Implementation Based on PANA for IoT
> Devices http://www.mdpi.com/1424-8220/13/11/14888). But I agree that if
> we assume DTLS we may assume that an EAP-TLS method would be
> reasonable. Nevertheless, I agree with Robert that we may not need to design
> a new EAP method for that.
> 
> Just my 0.02 cents.
> 
> >  Where would that fall in your view of the world?  I don't think it would be
> a Frankenprotocol at all, since EAP is designed to be extended that way.
> There also wouldn't be much new protocol work, as an EAP-DTLS method
> could be pretty similar to the existing EAP-TLS method.  Assuming something
> like that could meet our as-yet-undetermined requirements for this
> environment, would you consider that to be a successful outcome?
> >
> > Margaret
> >
> >
> >
> >
> Dept. Information and Communications Engineering (DIIC) Faculty of
> Computer Science-University of Murcia
> 30100 Murcia - Spain

---

From: Likepeng <[email-masked]>
Date: Wed, 19 Mar 2014 08:46:07 +0000

> I think this goes too far into the requirements space…  

Let's simplify that a little bit. How about this:

Identify suitable authentication and authorization mechanisms suitable for resource access in constrained environments.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Ace [mailto:[email-masked]] 代表 Margaret Wasserman
> 发送时间: 2014年3月17日 21:21
> 收件人: Carsten Bormann
> 抄送: Bert Greevenbosch; Hannes Tschofenig; [email-masked]
> >> I think there is more to it than "selection", especially since we may need to
> make some adjustments or define something new for the constrained case.
> >
> > Indeed.
> 
> adjusting or extending existing security mechanisms to meet the needs of this
> environment.
> 
> particular addressing dynamic and fine grained access control suitable for
> CoAP resource access requests in constrained environments.
> >>
> >> What do you think?
> 
> I think this goes too far into the requirements space…  I think we are planning
> to define the requirements and architecture as part of the charter, and I think
> that one area that needs a lot of discussion is what our requirements are for
> access control, and what roles the RS and AS will play in that.  For instance,
> we might decide that we want an attribute or role-based system where the
> authentication process returns various attributes and/or roles associated with
> the authenticated user, and that information is used by the RS to determine
> what access should be allowed.  In that case, the granularity of the access
> control could be application-specific and would be a matter of AS
> configuration and local implementation on the RS.
> 
> I want our charter to lean _strongly_ in the direction of preferring a solution
> that is based on existing security protocol standards, unless/until we can
> determine that none of them can meet the requirements, even with
> appropriate profiles, extensions or modifications.  I think that is pretty
> unlikely based on the breadth and variety of existing security protocols.  I
> think we should require a recharter to undertake development of a new
> security protocol.
> 
> 2) Selection of an existing authentication and authorization protocol that can
> serve as the basis of an authentication and authorization system for
> 3) Definition of whatever profiles, extensions or modifications are required to
> make the selected authentication and authorization protocol suitable for
> > We can try to weasel around this, but if this group is successful, the result
> will be the definition of certain new protocol components.
> much as possible is desirable, but there also is an objective to be met here.
> that leverages the existing crypto algorithms and security protocols available
> on the constrained device, based on the assumption that the device will also
> implement a constrained version of DTLS (as defined by the DICE WG).
> Where would that fall in your view of the world?  I don't think it would be a
> Frankenprotocol at all, since EAP is designed to be extended that way.  There
> also wouldn't be much new protocol work, as an EAP-DTLS method could be
> pretty similar to the existing EAP-TLS method.  Assuming something like that
> could meet our as-yet-undetermined requirements for this environment,
> would you consider that to be a successful outcome?
> 
> Margaret
> 
> 
> 
>

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 19 Mar 2014 08:41:19 -0400

Hi Rafa,

I would be very interested in hearing more about this work.  So, it would
be great if you could prepare an ID describing your implementation and the
results you achieved.

Thanks,
Margaret
On Mar 18, 2014 9:24 AM, "Rafa Marin Lopez" <[email-masked]> wrote:

> Hi Margaret, all
>
> > Depending on what you mean here, I might or might not agree...
> >
> environment
> As part of a research activity here at the University of Murcia, we
> created an initial design of an authentication service based on EAP for
> CoAP sometime ago. In other words, CoAP messages are used to transport EAP
> between the CoAP client (EAP authenticator) and the CoAP server (EAP peer/
> the constrained node). In particular, the EAP messages are directly
> transported in the CoAP message payload for this authentication service.
>  In this case, the EAP authenticator (CoAP client) can contact an external
> AAA server (which is one of the posible choices in ACE, as far as I have
> read).
>
> server and CoAP client based on the MSK. In our case, this security
> association might be based on DTLS or by using a new AUTH option we have
> defined to be included in any CoAP message (no need of DTLS in the second
> case).
>
> proof-of-concept with libcoap. It is still in PC platform but we have
> started to build the implementation in COOJA simulator (without DTLS so
> far). Nevertheless, our intention is also to test it with DTLS.
>
> I guess this could be also categorized as an EAP-based approach, though we
> do not know if it will be interesting for ACE members. If people think it
> is, we can prepare a short I-D explaining what we have until now.
>
> existing crypto algorithms and security protocols available on the
> constrained device, based on the assumption that the device will also
> In our case we have tested EAP-PSK since it uses AES-based cryptography.
> In fact, we have previous experience on that in real constrained devices
> we assume DTLS we may assume that an EAP-TLS method would be reasonable.
> Nevertheless, I agree with Robert that we may not need to design a new EAP
> method for that.
>
> Just my 0.02 cents.
>
> >  Where would that fall in your view of the world?  I don't think it
> would be a Frankenprotocol at all, since EAP is designed to be extended
> that way.  There also wouldn't be much new protocol work, as an EAP-DTLS
> method could be pretty similar to the existing EAP-TLS method.  Assuming
> something like that could meet our as-yet-undetermined requirements for
> this environment, would you consider that to be a successful outcome?
> >
> > Margaret
> >
> >
> >
> >

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 21 Mar 2014 11:07:20 +0100

Hi Margaret, Kapeng

Many thanks for your interest. We'll do it, then.

Best Regards.

El 19/03/2014, a las 13:41, Margaret Wasserman <[email-masked]> escribió:

> Hi Rafa,
> 
> I would be very interested in hearing more about this work.  So, it would be great if you could prepare an ID describing your implementation and the results you achieved.
> 
> Thanks,
> Margaret
>