Subject: Re: [mile] ROLIE Authorization and Authentication

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 2 Aug 2016 14:30:30 +0900

Hi Stephen and all,

In my understanding, we will have at least two drafts: one for general
purpose (current ROLIE core draft) and another for incident response
purpose.
If Option B talks about separate drafts that are neither of the two drafts,
I agree with you and Adam’s comment.

Apart from options A and B, it could be also fine to talk about
authorization and authorization in the general purpose draft (ROLIE core
draft) without mandating any specific technique.

Kind regards,
Take

From: mile [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Monday, August 1, 2016 12:52 AM
To: Banghart, Stephen A. (Fed) <[email-masked]>
Cc: [email-masked]
Subject: Re: [mile] ROLIE Authorization and Authentication

Hi Stephen,

If the primary purpose of ROLIE is to make public information available,
then leaving the authentication piece to separate drafts (your Option B)
seems to make sense.  My interest in ROLIE is centered on the ability to
syndicate configuration checklists, which is a class of security automation
information generally available to the public. 

I suspect that information sharing organizations may have a different
perspective.

I cannot authoritatively speak to which mechanism(s) would be best, but it
seems to be the case that OAUTH is widely used for many REST APIs in the
wild.  I have not seen XACML used in such a context.  I'm also not sure that
we should get into authorization.

Kind regards,

Adam

On Jul 29, 2016, at 12:52 PM, Banghart, Stephen A. (Fed)
<mailto:[email-masked]> wrote:

Hello all,
 
Following the discussion at IETF 96 on draft-ietf-mile-rolie-03, there are
some issues that we wanted to bring to the mailing list for discussion. This
e-mail references GitHub issue #34
(https://github.com/CISecurity/ROLIE/issues/34). The text from the issue is
duplicated here for convenience: 
 
Authentication and authorization can be handled using a number of different
mechanisms, for this reason it’s not clear if we can require a specific
mechanism in the ROLIE core. More discussion is needed with the working
group to determine a way forward. 
 
Proposals:
 
- A: Select one or more authentication and authorization mechanisms as
mandatory to implement (MTI).
- B: Address these issues in separate drafts. 

Support for OAUTH, http-auth, and XACML has been discussed in a limited
capacity previously. Given that deployed solutions may require different
authentication and authorization solutions based on differing deployment
requirements, we are concerned about requiring any single solution.
Furthermore, defining requirements for multiple solutions will add
significant page count to the draft. As a result, we are leaning towards
proposal B which would allow for some modularity in solutions through
additional drafts.
 
Are there any concerns with going this route?
 
If option A is desired, we could use some help from someone knowledgeable in
using authentication and authorization solutions with HTTP RESTful services.
 
Thanks,
Stephen Banghart
 
_______________________________________________
mile mailing list
mailto:[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Tue, 2 Aug 2016 15:23:42 +0000

Take and all,

Your understanding is correct, there will be a core ROLIE draft and a number of additional drafts for specific purposes (CSIRT, checklists, SWID, etc.). Option B would be to create an additional document that discusses authorization and authentication of ROLIE in more detail.

It looks like we're leaning towards option B at the moment, with at most a brief mention of authentication and authorization in the core, but no MTI or in-depth discussion. Is there any other input?

There are a few more issues raised at IETF 96 around ROLIE that Dave or I will address to the list in the coming days, and as always, we'd appreciate any feedback on those specific issues, or on ROLIE in general.

Thanks,
Stephen

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Tuesday, August 02, 2016 1:31 AM
To: 'Adam Montville' <[email-masked]>; Banghart, Stephen A. (Fed) <[email-masked]>
Cc: [email-masked]
Subject: RE: [mile] ROLIE Authorization and Authentication

Hi Stephen and all,

In my understanding, we will have at least two drafts: one for general purpose (current ROLIE core draft) and another for incident response purpose.
If Option B talks about separate drafts that are neither of the two drafts, I agree with you and Adam's comment.

Apart from options A and B, it could be also fine to talk about authorization and authorization in the general purpose draft (ROLIE core
draft) without mandating any specific technique.

Kind regards,
Take

Hi Stephen,

If the primary purpose of ROLIE is to make public information available, then leaving the authentication piece to separate drafts (your Option B) seems to make sense.  My interest in ROLIE is centered on the ability to syndicate configuration checklists, which is a class of security automation information generally available to the public. 

I suspect that information sharing organizations may have a different perspective.

I cannot authoritatively speak to which mechanism(s) would be best, but it seems to be the case that OAUTH is widely used for many REST APIs in the wild.  I have not seen XACML used in such a context.  I'm also not sure that we should get into authorization.

Kind regards,

Adam

On Jul 29, 2016, at 12:52 PM, Banghart, Stephen A. (Fed) <mailto:[email-masked]> wrote:

Hello all,
 
Following the discussion at IETF 96 on draft-ietf-mile-rolie-03, there are some issues that we wanted to bring to the mailing list for discussion. This e-mail references GitHub issue #34 (https://github.com/CISecurity/ROLIE/issues/34). The text from the issue is duplicated here for convenience: 
 
Authentication and authorization can be handled using a number of different mechanisms, for this reason it's not clear if we can require a specific mechanism in the ROLIE core. More discussion is needed with the working group to determine a way forward. 
 
Proposals:
 
- A: Select one or more authentication and authorization mechanisms as mandatory to implement (MTI).
- B: Address these issues in separate drafts. 

Support for OAUTH, http-auth, and XACML has been discussed in a limited capacity previously. Given that deployed solutions may require different authentication and authorization solutions based on differing deployment requirements, we are concerned about requiring any single solution.
Furthermore, defining requirements for multiple solutions will add significant page count to the draft. As a result, we are leaning towards proposal B which would allow for some modularity in solutions through additional drafts.

If option A is desired, we could use some help from someone knowledgeable in using authentication and authorization solutions with HTTP RESTful services.
 
Thanks,
Stephen Banghart

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Fri, 5 Aug 2016 14:20:44 +0000

All,

Overall consensus has landed on option B: a brief discussion for the needs for authentication and authorization in the core ROLIE document, then specific solutions presented in separate drafts. If there is no objection I'll close the issue.

Thanks,
Stephen

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Banghart, Stephen A. (Fed)
Sent: Tuesday, August 02, 2016 11:24 AM
To: Takeshi Takahashi <[email-masked]>
Cc: [email-masked]
Subject: Re: [mile] ROLIE Authorization and Authentication

Take and all,

Thanks,
Stephen

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Tuesday, August 02, 2016 1:31 AM
To: 'Adam Montville' <[email-masked]>; Banghart, Stephen A. (Fed) <[email-masked]>
Cc: [email-masked]
Subject: RE: [mile] ROLIE Authorization and Authentication

Hi Stephen and all,

Kind regards,
Take

Hi Stephen,

Kind regards,

Adam

Hello all,

 
Proposals:

 

Thanks,
Stephen Banghart

[email-masked]

---

From: [email-masked]
Date: Fri, 5 Aug 2016 11:36:12 -0400

Hello,

Were there more responses off list in addition to Take & Adam's?  Is there enough support to review multiple documents?  The chairs may have a better sense of that.

Thank you,
Kathleen

Sent from my iPhone

> On Aug 5, 2016, at 10:20 AM, Banghart, Stephen A. (Fed) <[email-masked]> wrote:
> 
> All,
>

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 8 Aug 2016 16:16:35 +0900

Hi all,

Right, we had better solicit more comments.

All, please give us any comment or feedback on this issue.
Comments such as "I do not care either way", or "I cannot say anything at
this moment, because" are also welcomed.

We could wait for 2 weeks to get consensus.
Since Stephen has sent the question to the mailing list on 29th July, we
could wait for further comments by 12th August.

Also, if you are willing to review these drafts, please let us know. We
appreciate that very much.

Cheers,
Take

> From: mile [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Saturday, August 6, 2016 12:36 AM
> To: Banghart, Stephen A. (Fed)
> Cc: [email-masked]
> Were there more responses off list in addition to Take & Adam's?  Is there
> enough support to review multiple documents?  The chairs may have a better
> sense of that.
> 
> Thank you,
> Kathleen
> 
> Sent from my iPhone
> 
> > Overall consensus has landed on option B: a brief discussion for the
needs
> for authentication and authorization in the core ROLIE document, then
> specific solutions presented in separate drafts. If there is no objection
> I'll close the issue.
> >
> > Thanks,
> > Stephen
> >
> > Your understanding is correct, there will be a core ROLIE draft and a
number
> of additional drafts for specific purposes (CSIRT, checklists, SWID,
etc.).
> Option B would be to create an additional document that discusses
> authorization and authentication of ROLIE in more detail.
> >
> > It looks like we're leaning towards option B at the moment, with at most
> a brief mention of authentication and authorization in the core, but no
MTI
> or in-depth discussion. Is there any other input?
> >
> > There are a few more issues raised at IETF 96 around ROLIE that Dave or
> I will address to the list in the coming days, and as always, we'd
appreciate
> any feedback on those specific issues, or on ROLIE in general.
> >
> > Thanks,
> > Stephen
> >
> I agree with you and Adam's comment.
> >
authorization
> and authorization in the general purpose draft (ROLIE core
> > I cannot authoritatively speak to which mechanism(s) would be best, but
> it seems to be the case that OAUTH is widely used for many REST APIs in
the
> > Following the discussion at IETF 96 on draft-ietf-mile-rolie-03, there
> are some issues that we wanted to bring to the mailing list for
discussion.
> This e-mail references GitHub issue #34
> (https://github.com/CISecurity/ROLIE/issues/34). The text from the issue
> is duplicated here for convenience:
> >
> mechanisms, for this reason it's not clear if we can require a specific
group
> to determine a way forward.
> >
> > Proposals:
> >
> > If option A is desired, we could use some help from someone
knowledgeable
> in using authentication and authorization solutions with HTTP RESTful
> services.
> >
> > Thanks,
> > Stephen Banghart
> >

---

From: Mio SUZUKI <[email-masked]>
Date: Mon, 8 Aug 2016 20:52:52 +0900

Hello,

I agree the option B, with one condition.
The condition is that we will surely have the authentication draft.
Protocol without security mechanism is scary to me.
 
Mio

> 2016/08/08 16:16、Takeshi Takahashi <[email-masked]> :
> 
> Hi all,
>

---

From: John Field <[email-masked]>
Date: Mon, 8 Aug 2016 10:47:56 -0400

I also support the notion of a separate draft for authentication and
authorization issues.  It makes sense to factor this out as it will be a
deployment-dependent decision.  We should probably state that doing some
sort of AuthN is a "SHOULD," but then delegate details to another
draft(s).  That is, using RFC 2119 compliant language of "SHOULD
authenticate" but leave it to the implementer to choose how, could be
appropriate here, since in certain circumstances, one could validly choose
not to do any authentication, as long as the implications of that choice
are fully understood.  I've added a comment on the git issue.

FWIW, I've had some experience with specifying/profiling AuthN mechanisms,
and so might be able to help there, once we get to that point.

Regards,
John

On Mon, Aug 8, 2016 at 7:52 AM, Mio SUZUKI <[email-masked]> wrote:

> >>> From: mile [mailto:[email-masked]] On Behalf Of Banghart,
> Stephen
> >> A. (Fed)
> >>> To: 'Adam Montville' <[email-masked]>; Banghart, Stephen
> A.
> >> (Fed) <[email-masked]>
> >>> Cc: [email-masked]

-- 

John P. Field | Security PM | Pivotal

Direct: (908) 962-3394 | jfield@ <[email-masked]>pivotal.io

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 10 Aug 2016 13:47:08 +0000

+1 for option B and John's comment: 
 
> We should probably state that doing some sort of AuthN is a "SHOULD," but then delegate details to another draft(s).  That is, using RFC 2119 compliant language of "SHOULD authenticate" but leave it to the implementer to choose how, could be appropriate here, since in certain circumstances, one could validly choose not to do any authentication, as long as the implications of that choice are fully understood.

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Takeshi Takahashi
Sent: Monday, August 08, 2016 3:17 AM
To: [email-masked]; 'Banghart, Stephen A. (Fed)' <[email-masked]>
Cc: [email-masked]
Subject: Re: [mile] ROLIE Authorization and Authentication

Hi all,

All, please give us any comment or feedback on this issue.
Comments such as "I do not care either way", or "I cannot say anything at this moment, because" are also welcomed.

We could wait for 2 weeks to get consensus.
Since Stephen has sent the question to the mailing list on 29th July, we could wait for further comments by 12th August.

Also, if you are willing to review these drafts, please let us know. We appreciate that very much.

Cheers,
Take

> Were there more responses off list in addition to Take & Adam's?  Is 
> there enough support to review multiple documents?  The chairs may 
> have a better sense of that.
> 
> Thank you,
> Kathleen
> 
> Sent from my iPhone
> 
needs
> specific solutions presented in separate drafts. If there is no 
> objection I'll close the issue.
> >
> > Thanks,
> > Stephen
> >
number
etc.).
MTI
appreciate
authorization
> then leaving the authentication piece to separate drafts (your Option 
> B) seems to make sense.  My interest in ROLIE is centered on the 
> ability to syndicate configuration checklists, which is a class of 
> security
automation
the
> wild.  I have not seen XACML used in such a context.  I'm also not 
> sure
that
discussion.
> (https://github.com/CISecurity/ROLIE/issues/34). The text from the 
> issue is duplicated here for convenience:
> >
> mechanisms, for this reason it's not clear if we can require a 
> specific mechanism in the ROLIE core. More discussion is needed with 
> the working
group
> capacity previously. Given that deployed solutions may require 
> different authentication and authorization solutions based on 
> differing deployment requirements, we are concerned about requiring any single solution.
> significant page count to the draft. As a result, we are leaning 
> towards proposal B which would allow for some modularity in solutions 
> through additional drafts.
> >
knowledgeable

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Thu, 18 Aug 2016 16:39:14 +0900

All,

Thank you very much for the comments.
As you can see from the discussion, the MILE community wishes to take the
option B.

Note that you can see the list of discussion issues on github.
Please feel free to join the discussion.
https://github.com/CISecurity/ROLIE/issues/

Best regards,
Take

> From: mile [mailto:[email-masked]] On Behalf Of Panos Kampanakis
> (pkampana)
> Sent: Wednesday, August 10, 2016 10:47 PM
> To: Takeshi Takahashi; [email-masked]
> Cc: [email-masked]
> > We should probably state that doing some sort of AuthN is a "SHOULD,"
but
> then delegate details to another draft(s).  That is, using RFC 2119
> compliant language of "SHOULD authenticate" but leave it to the
implementer
> to choose how, could be appropriate here, since in certain circumstances,
> one could validly choose not to do any authentication, as long as the
> implications of that choice are fully understood.
> 
> 
>