removed from the ACE-OAuth draft.
I agree that interest for this use case has been lukewarm at most in the
WG. I will remove that feature from the draft in the next update.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
x27;m not saying we shouldn't move this to a separate
draft, but let's keep our facts straight. I'm really curious to see
Hannes' paper once he can release it.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
__
y.
Hope that helps
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Seitz , Hannes Tschofenig
, Goeran Selander
, Samuel Erdtman ,
Erik Wahlstroem
A new version of I-D, draft-ietf-ace-oauth-authz-10.txt
has been successfully submitted by Ludwig Seitz and posted to the
IETF repository.
Name: draft-ietf-ace-oauth-authz
Revision: 10
Title
arding has happened).
I agree that onboarding is a valid concern (which is why I wrote
appendix B), but lets not delay draft-ietf-ace-oauth-authz any further
by adding a whole new set of functionality in it.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70
ask people to implement and review ... again).
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
profile drafts I'm co-authoring.
draft-ietf-ace-dtls-authorize
and
draft-ietf-ace-oscore-profile
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/lis
draft-ietf-ace-oauth-authz-11.txt
Date: Mon, 19 Mar 2018 05:50:19 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig
, Goeran Selander
, Samuel Erdtman ,
Erik Wahlstroem
A new version of I-D, draft-ietf-ace-oauth-authz-11.txt
has been successfully submitted by Ludwig Seit
com/ace-wg).
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
end of the day.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
On 2018-05-08 08:57, Ludwig Seitz wrote:
On 2018-05-07 18:44, Jim Schaad wrote:
I have been meaning to get this out for a while and have failed. A
doodle
poll to setup an interop event for this work is at
https://doodle.com/poll/k27g9r26bghvnytu If you want to participate
and none
of the
th Token Introspection Response"?
8.10 CWT Confirmation Methods Registry
Delete this section, as it has been moved to
draft-ietf-ace-cwt-proof-of-possession.
Done
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
n request that abbreviates to 4 and an "aud" claim in a CWT that
abbreviates to 5).
Do you see any concrete mismatch in the current registrations? The IANA
section has grown pretty large and an error might have slipped past our
vigilance.
/Ludwig
--
Ludwig Seitz, PhD
Sec
includes no request to IANA."
This should instead register the new profile identifier "mqtt_tls" in
the soon-to-be-created IANA registry for ACE profile identifiers. See
the DTLS profile for example:
https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-03#section-7
5. Securit
time?
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
document at the last F2F meeting. It
would be nice to get those changes published.
Done!
Please find draft -12 here:
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
hat I reordered the tests so that you only need
to run one server at a time for a batch of tests.
Sorry for the late changes, I hope we can test something on Wednesday.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
__
Hello ACE,
we held an interop on the implementations of
draft-ietf-ace-oauth-authz and draft-ietf-ace-dtls-authorize on May 30th.
We had 3 participants and some attendees that just listened in.
The implementations we tested were:
* ACE-Java by Ludwig Seitz (me), RISE SICS
https
Hello ACE,
I just wanted to announce that Jim and I will host a hackathon project
about the work in ACE at IETF 102
(https://trac.ietf.org/trac/ietf/meeting/wiki/102hackathon).
Please get in touch if you are interested to contribute or have suggestions.
Regards,
Ludwig
--
Ludwig Seitz, PhD
explains the different
field an MQTT Connect packet will have. We could add an example in hex
(MQTT being binary) but it wouldn't be as easy to read as the HTTP example.
Perhaps hex-code with explanations under the different parts of it as in:
45FC481AF56B1234 A527
p CWT-PoP aligned with
RFC 7800.
/Ludwig
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
Sending confidential email to a public mailing list again Hannes? You
are a rebel ;-)
--
Ludwig Seitz, PhD
Sec
roviding
additional privileges for the subject).
"
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
st we remove that paragraph.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
udwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
nts by Jim Schaad)
* Various editorial corrections by Hannes Tschofenig
/Ludwig
Forwarded Message
Subject: New Version Notification for draft-ietf-ace-oauth-authz-13.txt
Date: Mon, 2 Jul 2018 06:14:15 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig
, Goe
ves a CWT with the a confirmation claim, the
recipient MUST make sure that keys that may be contained in that claim
do not have a key identifier that duplicates one of a different key that
the recipient already recognizes."
Or shorter:
"Recipients MUST make sure that they do not accept i
On 2018-07-03 11:31, Ludwig Seitz wrote:
6. Client B gets 2 from AS bound via the cnf claim to KID="A"
This should of course read:
Client B gets T2 from AS ...
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70
draft-ietf-ace-oauth-authz:
cnf 8
rs_cnf 19
profile 10
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
in the two byte category (see quoted part
above the ~snip~).
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
o:i...@augustcellars.com>> wrote:
Note that the 1 byte range is 0-23
Currently in the 1 byte uint range we have 20-23 left unused
We could start assigning negative integer values in the 1 byte range if
needed.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-
27;req_cnf' and 'used_cnf' are going to replace the use of
'aud' and 'cnf' in the ACE request/response interactions)?.
Regards,
Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
in Constrained Environments (ACE)
Author : Ludwig Seitz
Filename: draft-ietf-ace-oauth-params-00.txt
Pages : 8
Date: 2018-09-18
Abstract:
This specification defines new parameters for the OAuth 2.0 token and
on Notification for draft-ietf-ace-oauth-authz-14.txt
Date: Wed, 19 Sep 2018 05:27:59 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig
, Goeran Selander
, Samuel Erdtman ,
Erik Wahlstroem
A new version of I-D, draft-ietf-ace-oauth-authz-14.txt
has been successfully
Subject: New Version Notification for draft-ietf-ace-oauth-authz-15.txt
Date: Thu, 27 Sep 2018 06:48:45 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig
, Goeran Selander
, Samuel Erdtman ,
Erik Wahlstroem
A new version of I-D, draft-ietf-ace-oauth-authz-15.txt
.
Forwarded Message
Subject: New Version Notification for draft-ietf-ace-oauth-authz-16.txt
Date: Tue, 2 Oct 2018 01:33:34 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig
, Goeran Selander
, Samuel Erdtman ,
Erik Wahlstroem
A new version of I-D, draft-ietf
rdingly. If there is room for
confusion OAuth should define a token type such as e.g. "request_token"
and make that a mandatory claim in the token or parameter of the request.
Therefore I would lean towards option 1.
/Ludwig
--
Ludwig Seitz, PhD
Security
e RS in an unauthorized resource
request may be confidential (e.g., because others must not know the
requested resources). The framework should mention in the security
considerations that the client must not send confidential data in the
unauthorized resource request.
I can add a sentence about
sent in
the introspection response, so there should not be any issue with the
cnf claim here.
--
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
ection of text to how to deal with multiple access tokens as
does this document. More methods of having multiple access tokens seem to
be coming down the path from the OAuth group. This appears to be a distinct
contradiction within the set of documents that should be resolved.
I will get
ons
(which I may have missed).
The idea was that OAuth could obsolete that document when they sort the
pop stuff out, without obsoleting the ACE framework. Thus a different
standalone document.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
cific resources and not only the target RS.
What if we want to identify the audience by its public key instead of an
URI?
What if a client wants to request a token for a group of RS identified
by a specific audience value (e.g. "thermostats-building-1")?
/Ludwig
--
L
the different apartments it is allowed to open.
If the token uses symmetric keys, as soon as the cleaning service sends
the token to one apartment, this apartment can open the other
apartments. This is the situation I want to avoid.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone
On 24/10/2018 03:44, Benjamin Kaduk wrote:
Just one minor note -- this is a great discussion to see happening!
On Tue, Oct 23, 2018 at 04:43:14PM +0200, Ludwig Seitz wrote:
On 22/10/2018 21:09, Jim Schaad wrote:
* Section 5.8.2 - If the RS is going to do introspection, can it send some
type
ments.
/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
tokens for one
client-RS pair can raise, I'm not disinclined to forbid them or at least
recommend against their use. However with audiences possibly addressing
overlapping sets of RSs this might be more difficult than it looks.
/Ludwig
--
Ludwig Seitz, PhD
Sec
non-mandatory in ACE (as
opposed to how it is in OAuth) and define defaults I'd agree to move
those into the two-byte space.
"profile" is arguably going to be used in less constrained scenarios
where more than one profile could be supported, so I'd agree to move
that t
On 23/10/2018 20:44, Jim Schaad wrote:
-Original Message- From: Ludwig Seitz
Sent: Tuesday, October 23, 2018 7:43 AM To: Jim Schaad
; draft-ietf-ace-oauth- au...@ietf.org Cc:
ace@ietf.org Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
Hallo Jim,
thank you for the review
rameter".
I've been registering (or at least trying to) claims separately from
parameters, leading to several double-registrations, when certain
key/value definitions are used both as claims and parameters (such as
scope, cnf etc).
/Ludwig
--
Ludwig Seitz, PhD
Security Lab,
to be "PoP"
and the default grant_type to be "client_credentials".
This will avoid having to send grant_type with every access token
request and token_type with every successful access token response.
Regards,
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
torage space, as long as it
stores at least one (in total, not per client).
Thus I'm curious what additional protections you would suggest are
feasible and necessary for the authz-info endpoint?
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
___
t are part of the audience.
The in-room consensus seemed to be that this should be a MUST NOT
instead and I agree.
/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
rence for 1. while Olaf has (in the Jabber at
IETF 103) expressed a preference for 2.
I would need some guidance from the WG on how to proceed here.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.o
On 23/11/2018 11:31, Ludwig Seitz wrote:
Hello ACE,
I have now addressed all WGLC comments (Jim Schaad's, Mike Jones' and
Stefanie Gerdes') except for this one:
"Do we need to write something about how a RS should handle the presence
of multiple tokens for the sa
comments.
Regards,
Ludwig
Forwarded Message
A new version of I-D, draft-ietf-ace-oauth-authz-17.txt
has been successfully submitted by Ludwig Seitz and posted to the
IETF repository.
Name: draft-ietf-ace-oauth-authz
Revision: 17
Title: Authentication and
I aware of any related to
this draft.
Ludwig Seitz
--
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
e to the client. I will remove
that requirement.
/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
On 11/12/2018 21:38, Jim Schaad wrote:
-Original Message-
From: Ace On Behalf Of Stefanie Gerdes
Sent: Tuesday, December 11, 2018 4:11 AM
To: Ludwig Seitz ; ace@ietf.org
Subject: Re: [Ace] Fwd: New Version Notification for
draft-ietf-ace-oauth-authz-
17.txt and draft-ietf-ace-oauth
t text though, since it currently only
talks about the needing to RS know which audiences it recognizes.
--
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
think the expiration time helps
in this case because it should be possible for the AS to
provide a token that expires earlier than the previous token.
Viele Grüße
Steffi
"Recent" here is meant as "most recently received". That is something
the RS definitely can track.
/Lud
On 13/12/2018 15:42, Stefanie Gerdes wrote:
Hi Ludwig,
On 12/12/2018 10:47 AM, Ludwig Seitz wrote:
The value of checking the iss field is indeed limited, but if present I
feel it MUST be checked.
The text does say that the RS must check the integrity of the token (see
5.8.1.1.)
"Sinc
properly.
Ciao
Hannes
I agree that your text improves the "verification" section.
I'm holding off with merging in order to wait for Steffi's confirmation
that it addresses her comments.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phon
ke sense to me.
Are you proposing we make the expires_in field mandatory? If so, why
isn't it mandatory already in OAuth (currently only RECOMMENDED)?
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
___
Ace mailin
tions describing the issue.
/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
parameter.
/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
ng 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
my example was perhaps not ideal, since it has an even bigger breach
as precondition. So under what conditions would an attacker get access
to a pop-key of an expired token? Steffi any ideas?
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70
?
/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
-ace-oauth-authz-18.txt
Date: Thu, 17 Jan 2019 06:45:56 -0800
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig
, Goeran Selander
, Samuel Erdtman ,
Erik Wahlstroem
A new version of I-D, draft-ietf-ace-oauth-authz-18.txt
has been successfully submitted by Ludwig Seitz and
For example my intent
was to use "aud" and "req_aud" for group identifiers
("temperatureSensorGroup4711") and other non-uri strings
(hash-of-public-key), which I cannot do with "resource". We therefore
decided to keep the "req_aud" parameter in d
Subject: New Version Notification for draft-ietf-ace-oauth-params-02.txt
Date: Tue, 29 Jan 2019 00:59:05 -0800
From: internet-dra...@ietf.org
To: Ludwig Seitz
A new version of I-D, draft-ietf-ace-oauth-params-02.txt
has been successfully submitted by Ludwig Seitz and posted to the
IETF
.
/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
these should have the JWT
Claim name filled in? It would seem that all of them should. If not a
comment about this is needed.
Fixed.
/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
On 30/01/2019 19:23, Jim Schaad wrote:
-Original Message- From: Ludwig Seitz
Sent: Wednesday, January 30, 2019 12:38 AM To: Jim Schaad
; draft-ietf-ace-oauth- au...@ietf.org Cc:
ace@ietf.org Subject: Re: Shepard review for
draft-ietf-ace-oauth-authz
Thank you Jim,
I'll upl
oceed here.
/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
Message
Subject: New Version Notification for draft-ietf-ace-oauth-authz-19.txt
Date: Thu, 31 Jan 2019 04:45:55 -0800
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig
, Goeran Selander
, Samuel Erdtman ,
Erik Wahlstroem
A new version of I-D, draft-ietf-ace-oauth
owever the
audience claim is defined to be "StringOrURI" so if someone defines an
audience identified by a String that is not an URI how does a client ask
for that with the resource parameter?
Or in short: Why don't you make your resource parameter mirror the "aud"
claim?
t, but I'd like the parameter to be
aligned with the JWT "aud" claim as well and currently "resource" is URI
while "aud" is StringOrURI.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
smi
or less
the same semantics) seems reasonable to me.
Do the chairs think that this would unduly delay the progress of
draft-ietf-ace-oauth-params?
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cryptographic Signature
's comment was a go-ahead with chair hat on.
I'm in the process of making the necessary updates to both
draft-ietf-ace-oauth-params and draft-ietf-ace-oauth-authz.
Expect an update in the next 10 minutes.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
s
Hello ACE,
I've updated both draft-ietf-ace-oauth-authz and
draft-ietf-ace-oauth-params to replace the "req_aud" parameter with the
equivalent "audience" parameter (not to be confused with "aud") from
draft-ietf-oauth-token-exchange.
/Ludwig
--
Ludwig
Hello all,
I would like to call the group's attention to this message of mine
(it was probably drowned out in the shepherd's review thread):
On 31/01/2019 10:40, Ludwig Seitz wrote:
Hello,
we have an unresolved review comment by Steffi that got lost in the
holiday seaso
t-ietf-ace-oauth-authz-21.txt
Date: Thu, 14 Feb 2019 01:27:00 -0800
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig
, Goeran Selander
, Samuel Erdtman ,
Erik Wahlstroem
A new version of I-D, draft-ietf-ace-oauth-authz-21.txt
has been successfully submitted by Ludwig Seitz and
8. This document has an IPR disclosure on it. If anybody has any problems
with the current disclosure then they need to speak up now.
Processing ...
The changes are currently only in the github version, I will upload a
new version of the draft soon.
/Ludwig
--
Ludwig Seitz, PhD
Security La
all can be provided. The intent was that these
error messages should only be sent when the access token is POSTed to
the authz-info endpoint.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cryptographic Signature
could still allow this. IANA
would still have the DE approve the assignment.
Ok so you mean not having "specification required" for -65536 to -257
and 256 to 65535 and not having "standards action" for -256 to 255 would
be ok?
Note that this would be different from the po
/agenda/
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Hello,
I would like 15 minutes to present and discuss the changes in
draft-ietf-oauth-authz and draft-ietf-oauth-params
/Ludwig
--
Ludwig Seitz, PhD
Security Lab
you were going for. Sorry for the slow uptake, and you
are indeed right. I will go through the mapping IANA sections and redue
the applicable policies to "expert review required" and "private use"
based on the number ranges.
/Ludwig
--
Lud
arded Message
Subject: New Version Notification for draft-ietf-ace-oauth-authz-22.txt
Date: Tue, 5 Mar 2019 01:52:31 -0800
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig
, Goeran Selander
, Samuel Erdtman ,
Erik Wahlstroem
A new version of I-D, draft-ietf-ace-oauth-aut
On 11/03/2019 23:24, Jim Schaad wrote:
Call Number 2 for agenda items. If you don't ask you will not be on the
agenda.
Jim
I'd like another 5 minutes to present
draft-secheverria-ace-client-disadvantaged-00
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70
08:53:03 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig
, Goeran Selander
, Samuel Erdtman ,
Erik Wahlstroem
A new version of I-D, draft-ietf-ace-oauth-authz-23.txt
has been successfully submitted by Ludwig Seitz and posted to the
IETF repository.
Name:
-ace-oauth-params-05.txt
Date: Mon, 25 Mar 2019 08:54:18 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz
A new version of I-D, draft-ietf-ace-oauth-params-05.txt
has been successfully submitted by Ludwig Seitz and posted to the
IETF repository.
Name: draft-ietf-ace-oauth-params
/Ludwig
Forwarded Message
Subject: New Version Notification for draft-ietf-ace-oauth-authz-24.txt
Date: Wed, 27 Mar 2019 02:16:23 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig
, Goeran Selander
, Samuel Erdtman ,
Erik Wahlstroem
A new vers
nsor networks,
and thus ACE would be very much less relevant if we didn't work on a
solution for MQTT as well.
Regards,
Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cryptographic Signature
__
are not exactly
"constrained-friendly", would it make sense to look at that as well to
define a "MQTT-SN-over-DTLS-based" profile?
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cry
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
good use case for transporting JOSE
keys in CBOR, but if such a case turns up, I would agree that touching
the encoding as little as possible is a good idea (=option 1 or 2).
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cryptographic
iviledge)
and not just stop using them.
==
6. "Then, if it wants to continue participating in the group
communication, the node has to request new updated keying material to
the KDC."
should be "... keying material from the KDC."
==
Sections 8. and 9.
Would be nice if
t;
This is incorrect use of requirements language. This 'MAY' can not be
tested and the arguments for claiming conformance to this requirement
would be quite diffuse. I suggest to require maintaining the Sender IDs.
Why should the GM change them in the first place?
Regards,
Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
, [JWS]) and RFC-number tags (e.g., [RFC7800]) for
the referenced RFCs.
I'm more inclined to have RFC number tags (makes it easier to look them
up without going via the bibliography), but it's mostly a matter of
taste. Do you think we should use one or the other consist
On 12/08/2019 23:59, Carsten Bormann wrote:
On Aug 12, 2019, at 14:08, Ludwig Seitz wrote:
As far as I gather from the comments (especially from Carsten), we'd solve this
by referencing section 6 of RFC 7049. I will consult with my co-authors, but I
think this is the right solution.
1 - 100 of 224 matches
Mail list logo
