Security Event Token (SET)
draft-ietf-secevent-token-13

Note: This ballot was opened for revision 10 and is now closed.

Benjamin Kaduk Yes

Alvaro Retana No Objection

Martin Vigoureux No Objection

Comment (2018-05-09 for -11)
No email
send info
Hello,

I'm not sure about the use of normative language in this sentence:
   Throughout this document, all figures MAY contain spaces

Warren Kumari No Objection

(Adam Roach; former steering group member) No Objection

No Objection (2018-05-08 for -11)
No email
send info
Thanks to the authors and everyone else who contributed to this document. I have
two minor editorial comments.

---------------------------------------------------------------------------

Please make sure these nits are fixed before sending on to the RFC editor:

  == Unused Reference: 'RFC7009' is defined on line 1066, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC7517' is defined on line 1078, but no explicit
     reference was found in the text

---------------------------------------------------------------------------

§4.3:

>  JWTs are now being used in application areas beyond the identity
>  applications in which they first appeared.  For instance, the Session
>  Initiation Protocol (SIP) Via Header Field [RFC8055] and Personal
>  Assertion Token (PASSporT) [RFC8225] specifications...

RFC 8055 defines a Received Realm parameter for the Via Header Field, not the
header field itself. Please rephrase as "...the Session Initiation Protocol
(SIP) Via Header Field Received Realm parameter [RFC8055]..."

(Alexey Melnikov; former steering group member) No Objection

No Objection (2018-05-09 for -11)
No email
send info
This document is in a good shape, thank you for your work on it.

A couple of nits:

First references to Base64url and UTF-8 need normative references.
Use RFC 3629 for the latter.

(Alissa Cooper; former steering group member) No Objection

No Objection (2018-05-09 for -11)
No email
send info
= Sec. 5.1 =

"Security events distributed through third parties or that carry
   personally identifiable information SHOULD be encrypted using JWE
   [RFC7516] or secured for confidentiality by other means."

The SHOULD here seems like it should be a MUST unless there are obvious exception cases.

= Sec. 5.2 =

"In
   addition to confidentiality and integrity (discussed above),
   implementers and profiling specifications MUST consider the
   consequences of delivery mechanisms that are not secure and/or not
   assured."

The "implementers ... MUST consider" construction seems like an odd use of normative language.

(Ben Campbell; former steering group member) No Objection

No Objection (2018-05-09)
No email
send info
Thanks for the work on this. 

Most of my comments have already been captured by others. I have one remaining observation, which I don't expect to be addressed: "SET" is going to be an exceptionally difficult Google search term. (I speak from experience as the one-time chair of the "SIMPLE" working group).

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Eric Rescorla; former steering group member) No Objection

No Objection (2018-05-06 for -10)
No email
send info
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4210



IMPORTANT
S 2.2.
>         *  a URI representing a user resource that was modified; or,
>   
>         *  a token identifier (e.g. "jti") for a revoked token.
>   
>         If used, the profiling specification SHOULD define the content and
>         format semantics for the value.  This claim is OPTIONAL, as the

Doesn't this need to be a MUST for interoperability?


S 4.
>         present but require that all be understood if the SET is to be
>         accepted.  Some profiles might require that only a single value be
>         present.  All such choices are within the scope of profiling
>         specifications to define.
>   
>   4.  Preventing Confusion between SETs and other JWTs

Why don't you include some claim that makes these unambiguously SETs?
That would at least prevent one directional confusion.

COMMENTS
S 2.2.
>   
>      "iss" (Issuer) Claim
>         As defined by Section 4.1.1 of [RFC7519], this claim contains a
>         string identifying the service provider publishing the SET (the
>         issuer).  In some cases, the SET issuer is not the issuer of the
>         security subject.  Therefore, implementers cannot assume that the

I am having a hard time reading this text. What do you mean "issue or
security subject?"


S 3.
>         Profiling specifications MUST define how the event subject is
>         identified in the SET, as well as how to differentiate between the
>         event subject's issuer and the SET issuer, if applicable.  It is
>         NOT RECOMMENDED for profiling specifications to use the "sub"
>         claim in cases in which the subject is not globally unique and has
>         a different issuer from the SET itself.

Doesn't this contradict the SHOULD i called out above?


S 5.1.
>      personally identifiable information SHOULD be encrypted using JWE
>      [RFC7516] or secured for confidentiality by other means.
>   
>      Unless integrity of the JWT is ensured by other means, it MUST be
>      signed using JWS [RFC7515] so that the SET can be authenticated and
>      validated by the SET recipient.

This MUST seems less helpful than it would otherwise be because it
doesn't specify what a valid signer is.


S 5.4.
>      When SETs are delivered asynchronously and/or out-of-band with
>      respect to the original action that incurred the security event, it
>      is important to consider that a SET might be delivered to a SET
>      recipient in advance of or behind the process that caused the event.
>      For example, a user having been required to log out and then log back
>      in again, may cause a token revoked SET to be issued, typically

Might be clearer to quote "token revoked"

(Ignas Bagdonas; former steering group member) No Objection

No Objection ()
No email
send info

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2018-05-07 for -10)
No email
send info
I guess this doc could also be informational as it "only" specifies a SET data structure and specific profiles will be defined in other documents that I guess would/could/should be stand-alone and as such might only need to refer this doc informatively. Was the intended state discussed in the working group? 

Minor question/comment:
sec  6: "SET issuers SHOULD take steps to minimize the chance of event correlation, when such correlation would constitute a privacy violation."
Should this maybe be a MUST given there is a constraint already given?

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ()
No email
send info