Subject: [Id-event] Stephen Farrell's No Objection on charter-ietf-secevent-00-00: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 13 Oct 2016 06:24:05 -0700

Stephen Farrell has entered the following ballot position for
charter-ietf-secevent-00-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-secevent/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have a few things I'd like to see improved before this WG is
approved. It's fine that that's done during external evaluation
though.

- What is an "identity related protocol"? I think it'd be way better
to be as specific as possible about what's meant here.

- I'm concerned that this bit is overly generic and will lead to
delays. It'd be better if the set of relevant events was better 
characterised in the charter before we start I think.

   "The Security Events working group will produce a standards-track
Event Token
   specification that includes:
    - A JWT extension for expressing security events
    - A syntax that enables event-specific data to be conveyed"

- I agree with Kathleen that only secure transports make sense
here and that can and should be in the charter.

- I think there's some missing text on privacy - we don't want this
work to end up helping e.g. advertisers track people across web
sites. And we don't want exchange of event information to lead 
to two co-operating partners being able to build up databases of
each others' employees. I'm not sure what'd be right to put in
the charter though.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 13 Oct 2016 14:32:03 +0100

Hi Stephen,

> https://datatracker.ietf.org/doc/charter-ietf-secevent/

Thank you. Let's do this while the charter is out for External Review.

>     - A syntax that enables event-specific data to be conveyed"

Agreed.

> here and that can and should be in the charter.

I am not convinced, see my reply to Kathleen.

> each others' employees. I'm not sure what'd be right to put in

If you can suggest some text, I can try to reword and find some place
for it.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Oct 2016 14:51:16 +0100

Hiya,

> Thank you. Let's do this while the charter is out for External Review.

Right, I hope it'll not be hard.

> I am not convinced, see my reply to Kathleen.

Well, the protocol payload may be signed or encrypted, sure
and there may be non-standard ways to communicate that say
between two processes on the same host, but I don't see why
there's a need for e.g. sending on port 80 ever. If there
is then it'd be good to have the WG justify that explicitly
maybe.

> If you can suggest some text, I can try to reword and find some place

TBH, I'm not sure. I think it depends on the better
characterising the set of events issue. If this is
mainly for inter-enterprise stuff about employees
that's one thing. If it's mainly for something else
on the public Internet then different considerations
may apply. But since I'm not clear on that (yet) I
don't know what'd make sense to put in the charter.

Cheers,
S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 13 Oct 2016 09:57:12 -0400

> is then it'd be good to have the WG justify that explicitly

In case my response wasn't clear, I would like to see something in the
charter - recommendations on how it is secured for transport and/or a
secure transport is used.

> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

-- 

Best regards,
Kathleen

---

From: Phil Hunt <[email-masked]>
Date: Thu, 13 Oct 2016 10:28:00 -0400

Why move a web protocol off the web?  You would want it to be HTTP but on another port?

These events are co-ordinating security events between web based systems.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Oct 13, 2016, at 9:51 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 13 Oct 2016 10:29:44 -0400

All lot of this has been discussed on the id-events mailing list.  But I think it is worth sharing what I think might be some of the collective conclusions so far.

Starting as far back in Prague and in Yokahama, many of us began to realize that there were many different async approaches emerging that did almost the same thing to share events. SCIM provisioning events, OAuth Token Revocation, OpenID Connect Logout, RISC Security Events, HEART Consents, were just s few all developing event formats.

It was informally agreed that this did not make sense and that leveraging JWT and its inherent JOSE signing and encryption was something we all wanted to achieve.  

Why Generic? (important question!)

The specs so far, are intentionally generic.  In extensive discussions we have observed that events have a lot of contextual specialization -- meaning that different subscribers care about different data points around seemingly similar events. Past XML approaches like Cybox/STIX tend to build a single rich event format that results in large payloads and complexity. While they have more portability they are more complex. Neither of these traits was viewed as desirable.

In contrast, SET is more like a “web” of pub/sub relationships where specific information is shared on a need to know basis. Because there is often a lot of “context” between pair-wise relationships, the amount of data transmitted is very minimal.  The actual transfer can be very RESTy event though it may be delivered asynchronously from the perspective of some other RESTful state change initiating action.  E.g. a user’s account resource is altered (e.g. suspended), causing the need to co-ordinate security components.

As an example of specialization, compare that a user account reset event might express many different things within SCIM (a provisioning protocols), RISC (a peer-wise security incident system), and Security Logging might all have a notion of an account “reset” event:
* The SCIM event, tracks this from a provisioning protocol letting subscribers know that the reset may need to be propagated.  The * RISC event signals that a provider has noted that an account has been reset, but the account might be under attack (password reset is an operational attack vector).  The RISC event lets the receiver know that the user in-common should be treated with a higher level of risk concern. 
* Security Logging:  tracks that a user was reset, but also captures the conditions around the reset (IP address, etc) much like a web access log.

In this scenario we actually did make it possible in SET to express all 3 event types simultaneously. However the pragmatic consensus in the group seems to be that likely subscribers will be specialized and that hybrid events would probably almost never be used and probably not desirable. RISC subscribes are probably not interested in getting other claims there are only interest in assessing risk around subjects. Provisioning systems meanwhile are trying to specifically co-ordinate state between domains. Logging systems tend to care about who did what.

Regarding Identity Related Protocol:

I think this wording could be improved. As with the name change from id-tokens to security tokens, I think the phrasing should be broadened slightly.  While a lot of SET event types are emerging from the contexts of specific protocols like OAuth (e.g. token revocation event), I think there is a higher level notion of “systems” rather than “protocols” that are relevant.

The reason why “identity” is important in the discussion, is that any system that contains personalization or personal data will eventually share common attack risks. You can devise many independent systems with no intension to share or co-ordinate data (e.g. a social network and a financial system), but even in these cases, users are often in common.  A user of a financial system may use their personal email as an account recovery vector, etc.

Amazingly, real users have a tendency to share their real names, their demographics data, their emails, and yes even passwords. This has set up the need for security “systems” to build relationships (in the case of RISC) that span business service providers that may have previously had no real need for a relationship.

Unfortunately, I haven’t got a suggestion. So far, this is an I know it when I see it situation. Hopefully someone can do better?

Phil

@independentid

> On Oct 13, 2016, at 9:32 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Stephen,
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 13 Oct 2016 10:43:23 -0400

> is then it'd be good to have the WG justify that explicitly

I am a bit confused. We’re talking about co-ordinated event security typically between HTTP  based (e.g. web) systems.

JWT was designed to be transported using HTTP.

Not sure I see why there is an issue with using HTTP port 80. 

Phil

@independentid

> On Oct 13, 2016, at 9:51 AM, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> Hiya,
> 
>>> https://datatracker.ietf.org/doc/charter-ietf-secevent/ <https://datatracker.ietf.org/doc/charter-ietf-secevent/>
>>> 
>>> 
>>>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Oct 2016 15:48:53 +0100

> Not sure I see why there is an issue with using HTTP port 80. 

Well, if we're transporting sensitive information
then I'm not clear why that'd even be sent on port
80 unless there's a specific need for that. Is
there?

S.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 13 Oct 2016 10:52:19 -0400

These are all web protocols.

JWT itself is secure enough to be URL safe. So, it’s seems prudent to build on that.

Phil

@independentid

> On Oct 13, 2016, at 10:48 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 13 Oct 2016 15:10:25 -0400

Stephen,

I think I see my disconnect. I thought you were suggesting we should not use http at all and do a new protocol. 

Assuming you mean use 443 as in HTTPS this makes sense for most implementations. The initial distribution draft requires it. 

Phil

> On Oct 13, 2016, at 10:52 AM, Phil Hunt <[email-masked]> wrote:
> 
> www.independentid.com
> [email-masked]

---

From: [email-masked]
Date: Thu, 13 Oct 2016 15:18:59 -0400

Please excuse typos, sent from handheld device 

> On Oct 13, 2016, at 3:10 PM, Phil Hunt (IDM) <[email-masked]> wrote:
> 
> Stephen,
> 

That's good.  We are just looking for some statement on security in the charter as well.  I think you didn't like the suggestions so far.  As such, could you come up with an appropriate sentence to add that addresses this concern?

Thanks,
Kathleen

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 13 Oct 2016 15:41:52 -0400

Ok will do. 

Phil

> On Oct 13, 2016, at 3:18 PM, [email-masked] wrote:
> 
> 
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 14 Oct 2016 10:47:00 -0400

Kathleen,

How about we change the line from (new text underlined):
A method for delivering events using HTTP POST (push)

To:
A secure method for assured delivery of events using HTTPS POST (push)

Regarding Stephen’s Concern about identity related protocols how about changing:

From:
Many identity related protocols require a mechanism to convey messages
between
systems in order to prevent or mitigate security risks, or to provide
out-of-band information as necessary. For example, an OAuth authorization
server, having received a token revocation request (RFC7009) may need to
inform affected resource servers; a cloud provider may wish to inform another
cloud provider of suspected fraudulent use of identity information; an
identity provider may wish to signal a session logout to a relying party.
To:

Many HTTP Web Services and APIs depend on a web security infrastructures that:
* identifies security subjects and regulates their access to services, 
* and provides profile and rights information to application. 
Examples are systems that leverage user-agent session cookies (RFC6265), and OAuth2 (RFC6749). In order to prevent or mitigate security risks, or to provide out-of-band information as necessary, these systems need to share security event messages. For example, an OAuth authorization server, having received a token revocation request (RFC7009) may need to inform affected resource servers; a cloud provider may wish to inform another cloud provider of suspected fraudulent use of identity information; an identity provider may wish to signal a session logout to a relying party and does not wish to rely solely upon clearing a session cookie.

Phil

@independentid

> On Oct 13, 2016, at 3:10 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Stephen,
>> 
>> On Oct 13, 2016, at 10:52 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>> On Oct 13, 2016, at 10:48 AM, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> 
>>>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 14 Oct 2016 11:05:58 -0400

That looks better.  If STephen agrees, I'll update the text.

Thanks,
Kathleen

On Fri, Oct 14, 2016 at 10:47 AM, Phil Hunt <[email-masked]> wrote:

> A *secure* method for *assured delivery of* events using HTTP*S* POST (push)
>
>
> *Many HTTP Web Services and APIs depend on a web security infrastructures that:*
>
> ** identifies security subjects and regulates their access to services, *
>
> ** and provides profile and rights information to application. *
>
> *Examples are systems that leverage user-agent session cookies (RFC6265), and OAuth2 (RFC6749). In order to prevent or mitigate security risks, or to provide out-of-band information as necessary, these systems need to share security event messages. *For example, an OAuth authorization server, having received a token revocation request (RFC7009) may need to inform affected resource servers; a cloud provider may wish to inform another cloud provider of suspected fraudulent use of identity information; an identity provider may wish to signal a session logout to a relying party *and does not wish to rely solely upon clearing a session cookie.*
>
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
>
> Assuming you mean use 443 as in HTTPS this makes sense for most
> implementations. The initial distribution draft requires it.
>
>
> That's good.  We are just looking for some statement on security in the
> charter as well.  I think you didn't like the suggestions so far.  As such,
> could you come up with an appropriate sentence to add that addresses this
> concern?
>
> Thanks,
> Kathleen
>
>
> Phil
>

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Oct 2016 16:22:08 +0100

On 14/10/16 15:47, Phil Hunt wrote:
> Kathleen,
> 
> How about we change the line from (new text underlined): A method for
> delivering events using HTTP POST (push)
> 
> To: A secure method for assured delivery of events using HTTPS POST
> (push)
> 
> From: Many identity related protocols require a mechanism to convey
> messages between systems in order to prevent or mitigate security
> risks, or to provide out-of-band information as necessary. For
> example, an OAuth authorization server, having received a token
> revocation request (RFC7009) may need to inform affected resource
> servers; a cloud provider may wish to inform another cloud provider
> of suspected fraudulent use of identity information; an identity
> provider may wish to signal a session logout to a relying party. 
>
> To:
> 
> Many HTTP Web Services and APIs depend on a web security
> infrastructures that: * identifies security subjects and regulates
> their access to services, * and provides profile and rights
> information to application. Examples are systems that leverage
> user-agent session cookies (RFC6265), and OAuth2 (RFC6749). In order
> to prevent or mitigate security risks, or to provide out-of-band
> information as necessary, these systems need to share security event
> messages. For example, an OAuth authorization server, having received
> a token revocation request (RFC7009) may need to inform affected
> resource servers; a cloud provider may wish to inform another cloud
> provider of suspected fraudulent use of identity information; an
> identity provider may wish to signal a session logout to a relying
> party and does not wish to rely solely upon clearing a session
> cookie.

Yes, that's better thanks.

S

> 
> Phil
> 
> @independentid www.independentid.com
> <http://www.independentid.com/>[email-masked]
> <mailto:[email-masked]>
> 
> 
> 
> 
> 
>>> I think I see my disconnect. I thought you were suggesting we
>>> should not use http at all and do a new protocol.
>>> 
>> That's good.  We are just looking for some statement on security in
>> the charter as well.  I think you didn't like the suggestions so
>> far.  As such, could you come up with an appropriate sentence to
>> add that addresses this concern?
>> 
>> Thanks, Kathleen
>>> 
>>> Phil
>>> 
>>>> @independentid www.independentid.com
>>>> <http://www.independentid.com/>[email-masked]
>>>> <mailto:[email-masked]>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Oct 13, 2016, at 10:48 AM, Stephen Farrell
>>>>> <[email-masked]
>>>>> <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> Well, if we're transporting sensitive information then I'm
>>>>> not clear why that'd even be sent on port 80 unless there's a
>>>>> specific need for that. Is there?
>>>>> 
>>>>> S.
>>>>> 
>>>> 
>>>> _______________________________________________ Id-event
>>>> mailing list [email-masked] <mailto:[email-masked]> 
>>>> <https://www.ietf.org/mailman/listinfo/id-event>
>> _______________________________________________ Id-event mailing
>> list [email-masked] <mailto:[email-masked]> 
>> <https://www.ietf.org/mailman/listinfo/id-event>
>