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

[Ballot comment]
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).

[Ballot comment]
= 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.

[Ballot comment]
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.

[Ballot comment]
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]..."

[Ballot comment]
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?

[Ballot comment]
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"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-secevent-token-10. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the JSON Web Token Claims registry on the JSON Web Token (JWT) registry page located at:

https://www.iana.org/assignments/jwt/

three, new registrations are to be made as follows:

Claim Name: Events
Claim Description: Security Events
Change Controller: IESG
Reference: [ RFC-to-be Section 2.2]

Claim Name: toe
Claim Description: Time of Event
Change Controller: IESG
Reference: [ RFC-to-be Section 2.2]

Claim Name: txn
Claim Description: Transaction Identifier
Change Controller: IESG
Reference: [ RFC-to-be Section 2.2]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the Structured Syntax Suffix Registry located at:

https://www.iana.org/assignments/media-type-structured-suffix/

a single registration is to be made as follows:

Name: JSON Web Token (JWT)
+suffix: +jwt
References: [RFC7519]
Encoding considerations: 8bit; JWT values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters.
Interoperability considerations: n/a
Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for +jwt SHOULD be as specified for "application/jwt". (At publication of this document, there is no fragment identification syntax defined for "application/jwt".)

The syntax and semantics for fragment identifiers for a specific "xxx/yyy+jwt" SHOULD be processed as follows:

For cases defined in +jwt, where the fragment identifier resolves per the +jwt rules, then process as specified in +jwt.

For cases defined in +jwt, where the fragment identifier does not resolve per the +jwt rules, then process as specified in "xxx/yyy+jwt".

For cases not defined in +jwt, then process as specified in "xxx/ yyy+jwt".
Security considerations: See the Security Considerations section of [RFC7519].
Contact: Michael B. Jones, mbj@microsoft.com
Author/Change controller: Security Events Working Group. The IESG has change control over this registration.
Registration Date: [ TBD-at-Registration ]
Modification Date(s): [ TBD-at-Registration ]

As this also requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

a single, new registration is to be made as follows:

Name: secevent+jwt
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be Section 2.3]

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-05-03):

From: The IESG
To: IETF-Announce
CC: secevent-chairs@ietf.org, Yaron Sheffer , yaronf.ietf@gmail.com, draft-ietf-secevent-token@ietf.org, kaduk@mit.edu, id-event@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Security Event Token (SET)) to Proposed Standard


The IESG has received a request from the Security Events WG (secevent) to
consider the following document: - 'Security Event Token (SET)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-05-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This specification defines the Security Event Token (SET) data
  structure.  A SET describes statements of fact from the perspective
  of an issuer about a subject.  These statements of fact represent an
  event that occurred directly to or about a security subject, for
  example, a statement about the issuance or revocation of a token on
  behalf of a subject.  This specification is intended to enable
  representing security- and identity-related events.  A SET is a JSON
  Web Token (JWT), which can be optionally signed and/or encrypted.
  SETs can be distributed via protocols such as HTTP.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-secevent-token/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-secevent-token/ballot/


No IPR declarations have been submitted directly on this I-D.

Shepherd writeup: draft-ietf-secevent-token by Yaron Sheffer

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. This is appropriate: the document standardizes a data format.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The document defines the format of Security Event Tokens (SETs), which allow multiple entities to communicate about identity-related events. The format is intended to be common to multiple higher-level specifications, which are expected to be defined outside the IETF.

Working Group Summary

The working group had to go through a second last call, after we failed to reach consensus in the first LC. The second last call did result in consensus that the draft is ready and usable for our "customers", i.e. the specifications that will be profiling it.

Document Quality

We are not aware of current implementations, other than those that implement a trivial subset of the format. A large number of major vendors took part in discussions, and multiple industry groups are expected to use this format.

Personnel

Yaron Sheffer is the document shepherd. Kathleen Moriarty is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed -05 in full, as well as the detailed diff to -06 and -07. I believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Nothing special.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No special concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

All the key players have chimed in, and almost all support publication.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are only two warnings related to unused references, and one about an I-D that has since been published.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

As far as I know, this does not apply.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are several values being registered, and they are consistent with the body of the document. There are no new registries.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None, other than some base64 values.