Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt

2023-03-13 Thread Sebastian Echeverria
Hello,

I am also not aware of any IPR on our side, and I confirm I’m willing to 
co-author the document.

Thanks,

---
Sebastian Echeverria
Tactical and AI-enabled Systems (TAS)
Software Engineering Institute
Carnegie Mellon University


Sebastian Echeverria

From: Ace  on behalf of Marco Tiloca 

Date: Monday, March 13, 2023 at 3:11 PM
To: Daniel Migault , Ace Wg 
Subject: Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt
Hi Daniel and all,
On 2023-03-13 18:36, Daniel Migault wrote:
Hi everyone,

This email starts a WGLC for draft-ietf-ace-revoked-token-notification which 
ends on March 27. Please provide your support and feed backs by that time. We 
will take advantage of the IETF116 session to solve any remaining discussions 
on that draft.

I am also looking for someone interested in being the document shepherd: Please 
volunteer!

To the co-authors I am looking at:
- 1) a heads-up regarding the implementations.

==>MT
An implementation from Marco Rasori is available at [1], as building on the 
implementation of the ACE framework at [2]. It is planned to make a pull 
request of [1] onto [2].

[1] https://bitbucket.org/marco-rasori-iit/ace-java/src/ucs/

[2] https://bitbucket.org/marco-tiloca-sics/ace-java

<==


- 2) a confirmation that they are or not aware of any IPR

==>MT
I do not have and I am not aware of any IPR on this document.
<==


- 3)  a confirmation that they are willing to co-author the document.

==>MT
I am willing to be a co-author of this document.


Best,
/Marco
<==



Yours,
Logan and Daniel


On Mon, Mar 13, 2023 at 11:36 AM 
mailto:internet-dra...@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Authentication and
Authorization for Constrained Environments (ACE) WG of the IETF.

   Title   : Notification of Revoked Access Tokens in the 
Authentication and Authorization for Constrained Environments (ACE) Framework
   Authors : Marco Tiloca
 Ludwig Seitz
 Francesca Palombini
     Sebastian Echeverria
 Grace Lewis
   Filename: draft-ietf-ace-revoked-token-notification-04.txt
   Pages   : 59
   Date: 2023-03-13

Abstract:
   This document specifies a method of the Authentication and
   Authorization for Constrained Environments (ACE) framework, which
   allows an Authorization Server to notify Clients and Resource Servers
   (i.e., registered devices) about revoked Access Tokens.  The method
   allows Clients and Resource Servers to access a Token Revocation List
   on the Authorization Server, with the possible additional use of
   resource observation for the Constrained Application Protocol (CoAP).
   Resulting (unsolicited) notifications of revoked Access Tokens
   complement alternative approaches such as token introspection, while
   not requiring additional endpoints on Clients and Resource Servers.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-revoked-token-notification/<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-revoked-token-notification%2F=05%7C01%7Cmarco.tiloca%40ri.se%7C6e109d1b535245f2de8c08db23e98fd8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638143258281813215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gYpZlIuI%2BzStJC5ry%2FAgPKsG0dsCQFlP6YvWA61JJV4%3D=0>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-ace-revoked-token-notification-04.html<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-ace-revoked-token-notification-04.html=05%7C01%7Cmarco.tiloca%40ri.se%7C6e109d1b535245f2de8c08db23e98fd8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638143258281813215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=8A%2FhfRSRo848%2BPuH9tENHNbjyZ5tLM1rbdbt%2FOEaBY8%3D=0>

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-revoked-token-notification-04<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-ace-revoked-token-notification-04=05%7C01%7Cmarco.tiloca%40ri.se%7C6e109d1b535245f2de8c08db23e98fd8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638143258281813215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=p7r7kMc09mEkD3tHNYmvwMygX0OmjHU1MlaThzk%2F7sk%3D=0>

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
Ace mailing list
Ace@ietf.org<mailto:Ace@ietf.org>
https://www.ietf.org/mailman/listinfo/ace<https:

Re: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21

2019-02-20 Thread Sebastian Echeverria
Hello Jim,

Thanks for your comments! I understand and I agree. In any case, my point 
wasn’t really that there was no situation in which a 4.01 reply would make 
sense. My point was that, in the way the draft is currently written, it asks a 
RS to return 4.01 in certain cases, and in at least some of those cases, the RS 
can’t really reply with a 4.01 (and as Carsten mentioned, the RS can’t even get 
the actual request). I am not sure what the best way to clarify that is, but 
when we were trying to implement that part of the draft, it was confusing 
because we couldn’t really comply with what is requested there, at least in the 
specific case I described.

As a separate comment, I am not sure I understand the specific examples you 
mention. From the draft (same section 5.8.2), it looks as if, in the first case 
you are describing (different action on the same resource), 4.05 should be 
returned. And in your second example (same action on a different resource), it 
looks as if the RS should return 4.03. Is this correct? We are just trying to 
ensure we are implementing error handling properly here. This is only a comment 
on these specific examples; I am not saying there is no situation where 4.01 
could be returned.

Sebastian

From: Jim Schaad 
Date: Tuesday, February 19, 2019 at 6:17 PM
To: Sebastian Echeverria , "ace@ietf.org" 

Subject: RE: [Ace] Comment about error responses in 
draft-ietf-ace-oauth-authz-21

Sebastian,

The 4.01 is not restricted to just the DTLS case.  One could get this error 
from just trying to get the resource on the schema coap rather than coaps.  
However, this could occur even in the DTLS profile case.  Consider the 
situation of the following:

I have a token which allows me to do a get on a resource
I setup the DTLS session with that token and preform the get
I then attempt to do a PUT on that same resource.

This would then return a 4.01 (Unauthorized) because I don’t have a valid 
access token for the purpose of doing the action.  The same thing would be true 
if I attempted to do a GET on a different resource.

Jim


From: Ace  On Behalf Of Sebastian Echeverria
Sent: Monday, February 18, 2019 6:59 AM
To: ace@ietf.org
Subject: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21

Hello,

I have a short comment about error responses from an RS in 
draft-ietf-ace-oauth-authz-21. More specifically, my question is about section 
5.8.2. In the second paragraph, it states “The response code MUST be 4.01 
(Unauthorized) in case the client has not performed the proof-of-possession, or 
if RS has no valid access token for the client.” I am assuming this means that 
if the client is trying to access a resource and sending a pop key id that is 
not known by the RS, either because the RS has never seen it or because it is 
associated to a token that has already been removed from the RS, then this is 
how the RS should reply.

If this is the case, I am a bit confused on how to implement this when using 
the DTLS profile. When using this profile, a client will first try to establish 
a DTLS session with the RS when accessing a resource. Once the session is 
established, it will actually try to access the resource over that DTLS 
connection. The pop key id to be used is sent when establishing the DTLS 
connection in the DTLS handshake messages, but if the RS does not have a 
key+token associated to that id for whatever reason, then it will cancel the 
DTLS handshake. If the DTLS handshake is never completed, then the RS can’t 
really send a reply at all, much less a 4.01 reply.

Thanks,

Sebastian Echeverria
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


[Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21

2019-02-18 Thread Sebastian Echeverria
Hello,

I have a short comment about error responses from an RS in 
draft-ietf-ace-oauth-authz-21. More specifically, my question is about section 
5.8.2. In the second paragraph, it states “The response code MUST be 4.01 
(Unauthorized) in case the client has not performed the proof-of-possession, or 
if RS has no valid access token for the client.” I am assuming this means that 
if the client is trying to access a resource and sending a pop key id that is 
not known by the RS, either because the RS has never seen it or because it is 
associated to a token that has already been removed from the RS, then this is 
how the RS should reply.

If this is the case, I am a bit confused on how to implement this when using 
the DTLS profile. When using this profile, a client will first try to establish 
a DTLS session with the RS when accessing a resource. Once the session is 
established, it will actually try to access the resource over that DTLS 
connection. The pop key id to be used is sent when establishing the DTLS 
connection in the DTLS handshake messages, but if the RS does not have a 
key+token associated to that id for whatever reason, then it will cancel the 
DTLS handshake. If the DTLS handshake is never completed, then the RS can’t 
really send a reply at all, much less a 4.01 reply.

Thanks,

Sebastian Echeverria
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] ACE Implementation for Disadvantaged Environments

2019-01-30 Thread Sebastian Echeverria
Hello Michael,

Thanks! Answers to your questions here:

 - We used plain Contiki, since we forked from 6lbr, which itself forked from 
plain Contiki (we did this since 6lbr already had CoAPs functionality 
implemented). We have given thought to migrating to Contiki-ng, so that could 
happen at some point.

- By disadvantaged networks we do mean something similar to constrained 
networks as defined in RFC 7228. In the past we've mostly focused on DIL 
(Disconnected, intermittent, and limited bandwidth) environments mostly due to 
the mobility of the devices involved and the environmental conditions of our 
use cases. But most of the constraints are similar.

 - We are striving to get it down to around 250 kb, but we haven't spent that 
much time yet trimming it down. With some work, we should probably be able to 
get there.

Thanks for your comments!

Sebastian

On 1/28/19, 6:51 PM, "Michael Richardson"  wrote:


Thanks for the report!

    Sebastian Echeverria  wrote:
> * We used Contiki as the base/OS for the code. More specifically, we
> forked

Contiki, or contiki-ng?

> from the 6lbr project (https://github.com/cetic/6lbr), as that version
> already had some code for handling DTLS connections and AES 
encryption in
> it.


> * We are using the TI CC2538dk board as our constrained target 
platform.


> * The implementation has support for the DTLS profile, using 
pre-shared keys,
> as this was enough for our use case.

Yes, but often not really enough for a deployment where we need certificates
or raw public keys, and this may have significant affects on packet sizes 
:-(

> * We modified the Erbium CoAP server in 6lbr to be able to 
simultaneously
> listen for CoAP and CoAPs connections (using TinyDTLS underneath).

That's an interesting and useful change.

> * The implementation has some additional optional features related to 
our
> disadvantaged network environments, such as bootstrapping of the PSK
> credentials, and detecting revoked tokens through introspection.

When you say "disadvantaged", I think that you mean "constrained",
as per RFC7228?

> * The current binary is around 300 kb, which is good enough for the 
512 kb
> flash on the TI boards, though it may be a bit too large for a class 
II
> device. We can probably make it a bit smaller. In terms of RAM, it 
fits in
> the 32 KB available on the TI boards.

The key number is 256K, so that one can double buffer the firmware image.

--
]   Never tell me the odds! | ipv6 mesh 
networks [
]   Michael Richardson, Sandelman Software Works|IoT architect  
 [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails  
  [



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] ACE Implementation for Disadvantaged Environments

2019-01-28 Thread Sebastian Echeverria
Hi Hannes,

Regarding your questions:

1. “How easy do you think would it be to port the code to some other OS? (or in 
other words: how tightly have you coupled it to Contiki?)”


-  Most of the code is called by Contiki processes, so it is not that 
coupled, and the cn-cbor and TinyDTLS dependencies are independent from 
Contiki. The code depends on two main things from Contiki: the Erbium CoAP 
server, and the CFS file system. The coupling with Erbium is not that strong, 
but wherever the code is ported, it would need a CoAP/CoAPs server on that OS, 
or the actual porting of a subset of Erbium (which I guess is doable, but it 
may be substantial work). The dependency on the CFS file system is for storing 
keys and tokens, and that would need to be adapted to whatever another OS 
offers, though this dependency is fairly contained in one module, and changes 
should not be that hard.

2. “Is the COSE/CWT parsing library separable from the rest? “


-  Yes, it is fairly separable from the rest, other than the fact that 
it uses cn-cbor for cbor parsing, and TinyDTLS for AES decryption. However, at 
the moment it is very limited in terms of COSE parsing, only supporting the 
COSE wrapper and cypher suites we are actually using/supporting in our 
implementation.

3. “For the 300 Kb flash: does this contain the firmware update mechanism?”


-  No, this does not include the firmware update mechanism.

Any more questions, just let me know.

Thanks,

Sebastian

From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com]
Sent: Monday, January 28, 2019 10:19 AM
To: Sebastian Echeverria 
Cc: Grace A Lewis ; ace@ietf.org; Dan Klinedinst 

Subject: RE: ACE Implementation for Disadvantaged Environments

Hi Sebastian,

Thanks for the details. How easy do you think would it be to port the code to 
some other OS? (or in other words: how tightly have you coupled it to Contiki?)

Is the COSE/CWT parsing library separable from the rest?

For the 300 Kb flash: does this contain the firmware update mechanism?

Ciao
Hannes

From: Sebastian Echeverria 
mailto:sechever...@sei.cmu.edu>>
Sent: Montag, 28. Januar 2019 16:06
To: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Cc: Grace A Lewis mailto:gle...@sei.cmu.edu>>; 
ace@ietf.org<mailto:ace@ietf.org>; Dan Klinedinst 
mailto:djklinedi...@cert.org>>
Subject: Re: ACE Implementation for Disadvantaged Environments

Hello,

Here is some more information about it:

-  We used Contiki as the base/OS for the code. More specifically, we 
forked from the 6lbr project (https://github.com/cetic/6lbr), as that version 
already had some code for handling DTLS connections and AES encryption in it.
-  We are using the TI CC2538dk board as our constrained target 
platform.
-  The implementation has support for the DTLS profile, using 
pre-shared keys, as this was enough for our use case.
-  The implementation handles CWT tokens.
-  We modified the Erbium CoAP server in 6lbr to be able to 
simultaneously listen for CoAP and CoAPs connections (using TinyDTLS 
underneath).
-  The implementation uses the cn-cbor library for decoding CBOR data.
-  The implementation supports receiving tokens at the authz-info 
endpoint, and then giving access to a couple of sample resources based on the 
claims from the received tokens.
-  The implementation has some additional optional features related to 
our disadvantaged network environments, such as bootstrapping of the PSK 
credentials, and detecting revoked tokens through introspection.
-  The current binary is around 300 kb, which is good enough for the 
512 kb flash on the TI boards, though it may be a bit too large for a class II 
device. We can probably make it a bit smaller. In terms of RAM, it fits in the 
32 KB available on the TI boards.

Best,

---
Sebastian Echeverria
Tactical Technologies Group (TTG)
Software Engineering Institute
Carnegie Mellon University



From: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Date: Monday, January 28, 2019 at 5:05 AM
To: Grace Lewis mailto:gle...@sei.cmu.edu>>, 
"ace@ietf.org<mailto:ace@ietf.org>" mailto:ace@ietf.org>>
Subject: RE: ACE Implementation for Disadvantaged Environments

Congrats to the work. Could you say a little bit the (constrained) resource 
server implementation?

Ciao
Hannes

From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of 
Grace A Lewis
Sent: Mittwoch, 23. Januar 2019 19:12
To: ace@ietf.org<mailto:ace@ietf.org>
Subject: [Ace] ACE Implementation for Disadvantaged Environments

Hello,

I just wanted to make the group aware of our ACE implementation (SEI-ACE), 
which includes an implementation for a resource-constrained server.

Details available in this news article: 
https://www.sei.cmu.edu/news-events/news/article.cfm?assetid=539184

Article includes the link to our Git repo.

Enjoy!

- Grace Lewis

__

Re: [Ace] ACE Implementation for Disadvantaged Environments

2019-01-28 Thread Sebastian Echeverria
Hello,

Here is some more information about it:


  *   We used Contiki as the base/OS for the code. More specifically, we forked 
from the 6lbr project (https://github.com/cetic/6lbr), as that version already 
had some code for handling DTLS connections and AES encryption in it.
  *   We are using the TI CC2538dk board as our constrained target platform.
  *   The implementation has support for the DTLS profile, using pre-shared 
keys, as this was enough for our use case.
  *   The implementation handles CWT tokens.
  *   We modified the Erbium CoAP server in 6lbr to be able to simultaneously 
listen for CoAP and CoAPs connections (using TinyDTLS underneath).
  *   The implementation uses the cn-cbor library for decoding CBOR data.
  *   The implementation supports receiving tokens at the authz-info endpoint, 
and then giving access to a couple of sample resources based on the claims from 
the received tokens.
  *   The implementation has some additional optional features related to our 
disadvantaged network environments, such as bootstrapping of the PSK 
credentials, and detecting revoked tokens through introspection.
  *   The current binary is around 300 kb, which is good enough for the 512 kb 
flash on the TI boards, though it may be a bit too large for a class II device. 
We can probably make it a bit smaller. In terms of RAM, it fits in the 32 KB 
available on the TI boards.

Best,

---
Sebastian Echeverria
Tactical Technologies Group (TTG)
Software Engineering Institute
Carnegie Mellon University



From: Hannes Tschofenig 
Date: Monday, January 28, 2019 at 5:05 AM
To: Grace Lewis , "ace@ietf.org" 
Subject: RE: ACE Implementation for Disadvantaged Environments

Congrats to the work. Could you say a little bit the (constrained) resource 
server implementation?

Ciao
Hannes

From: Ace  On Behalf Of Grace A Lewis
Sent: Mittwoch, 23. Januar 2019 19:12
To: ace@ietf.org
Subject: [Ace] ACE Implementation for Disadvantaged Environments

Hello,

I just wanted to make the group aware of our ACE implementation (SEI-ACE), 
which includes an implementation for a resource-constrained server.

Details available in this news article: 
https://www.sei.cmu.edu/news-events/news/article.cfm?assetid=539184

Article includes the link to our Git repo.

Enjoy!

- Grace Lewis

__
Grace A. Lewis, Ph.D.
Principal Researcher and TTG Initiative Lead
Carnegie Mellon Software Engineering Institute
Software Solutions Division (SSD)
Tactical Technologies Group (TTG)

4500 Fifth Ave. #5412
Pittsburgh, PA 15213
Phone: (412) 268-5851
http://www.sei.cmu.edu/staff/glewis

“A change in perspective is worth 80 IQ points” --- Alan Kay
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] Security of the Communication Between C and RS

2018-12-20 Thread Sebastian Echeverria
Hello,

>> If it is detected the AS would revoke the token. Then the client _could_ use 
>> client introspection to get that information. Note that this is what the CMU 
>> people are looking at.

Yes, handling compromised RSs is in fact something that we have been looking 
into. Our main concern is that in our scenarios, the environment is expected to 
be very hostile and connection is limited and intermittent (disadvantaged or 
DIL networks). Since we wanted to add some support for revoking tokens, without 
having to modify the framework to handle token revocation explicitly, what we 
ended up doing was using client introspection, along with some caveats and some 
considerations, to be able to add this functionality, besides also having ways 
to handle expired tokens. The main advantage of this is, again, that we aren't 
really modifying or even extending the ACE framework, but just taking advantage 
of functionality that is already there to implement this functionality, which 
makes sense in our use case.

In fact, we were looking into writing a BCP-like document suggesting ways to do 
this based on what we did. We were envisioning this as maybe the starting point 
of a document containing practices on how to better handle client 
communications with OAuth/ACE when we are dealing with disadvantaged networks 
and hostile environments. If there is interest in the group, we could share 
that document here, and maybe discuss what other practices could be added to it.

Thanks,

---
Sebastian Echeverria
Tactical Technologies Group (TTG)
Software Engineering Institute
Carnegie Mellon University



-Original Message-
From: Ludwig Seitz [mailto:ludwig.se...@ri.se] 
Sent: Wednesday, December 19, 2018 8:24 AM
To: Hannes Tschofenig ; Stefanie Gerdes 
; Jim Schaad ; ace@ietf.org
Subject: Re: [Ace] Security of the Communication Between C and RS

On 19/12/2018 14:04, Hannes Tschofenig wrote:
> Thanks, Ludwig. The list of steps below help me to understand the concern.
> 
> 
> 
> 
> 1.) C obtains token and pop-key from AS
> 2.) C transmits token to RS and sets up secure communication (e.g.
> DTLS-PSK) using the pop-key
> 3.) C sends secure requests to the RS
> 4.) token expires, an attacker manages to get hold of the pop-key
> 5.) C continues to send requests containing sensitive information to the RS , 
> attacker can now read the messages and spoof positive responses from the RS. 
> C never notices that the token is invalid and that it is actually talking to 
> the attacker.
> 

> 
> 
> In step (4) you tie the expiry of the token to the attacker getting 
> hold of the key. What happens if the attacker gets hold of the pop key 
> before the token expires?

If it is detected the AS would revoke the token. Then the client _could_ use 
client introspection to get that information. Note that this is what the CMU 
people are looking at.

> Additionally, if you use DTLS/TLS just having the PoP key still 
> requires the attacker to run a new DTLS/TLS handshake with the RS.

If the pop-key was used as a basis for doing a DTLS-PSK handshake, the attacker 
should be able to hijack the connection and impersonate either party.


> It would also be useful to know where the attacker got the PoP key 
> from and how you can even detect the compromise.

That is a different story entirely. You could imagine the case of an RS 
improperly deleting an expired token and the associated pop-key, and then being 
subject to a physical attack that recovers that information.

> 
> Additionally, there is the question why the RS wouldn't stop 
> communicating if the token expired since it has that information.

The RS would indeed stop, but since the token is opaque to the client, it has 
no way of knowing that the token has expired, and our clever attacker is using 
the pop-key to impersonate the RS and maintain the illusion that the connection 
is still alive an running.

> Normally, the idea is that the RS has a protected resource and the 
> client wants to access it. That's why the RS is asking the client to 
> send a token that gives it access.
>

Yes but say e.g. that the RS is a message broker and the client is a publisher, 
writing sensitive data to the RS.


I think Steffi's point definitely warrants text in the security 
considerations, outlining how a client could detect that a token has 
expired.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace