Discussion:
[OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
(too old to reply)
Justas Janauskas
2012-08-05 10:30:55 UTC
Permalink
Hello,

Sorry if this is not the right group to send this message; I am new here.

I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.

I made a small program to test correctness of an example and it shows
that it is incorrectly calculated in the document:
https://gist.github.com/3263677

I have also implemented an example from previous draft 00, section 1.2
which shows that request MAC is calculated correctly there:
https://gist.github.com/3263765

Thank you,
Justas Janauskas
Justin Richer
2012-08-08 15:08:08 UTC
Permalink
Thanks Justas. The MAC document is currently without an editor within
the WG, so this is the best place to record the error.

A wider note to the WG: I wouldn't mind taking over editorship of the
MAC token document so long as I could get a co-editor with enough
cryptographic expertise to make sure all the magical crypto bits work
like they should. I've sent an email to the chairs saying as much, as well.

-- Justin
Post by Justas Janauskas
Hello,
Sorry if this is not the right group to send this message; I am new here.
I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.
I made a small program to test correctness of an example and it shows
https://gist.github.com/3263677
I have also implemented an example from previous draft 00, section 1.2
https://gist.github.com/3263765
Thank you,
Justas Janauskas
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
William Mills
2012-08-08 15:22:39 UTC
Permalink
Justin,

Count me in to help revive this and get it done.

-bill


________________________________
From: Justin Richer <***@mitre.org>
To: ***@ietf.org
Sent: Wednesday, August 8, 2012 8:08 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Thanks Justas. The MAC document is currently without an editor within
the WG, so this is the best place to record the error.

A wider note to the WG: I wouldn't mind taking over editorship of the
MAC token document so long as I could get a co-editor with enough
cryptographic expertise to make sure all the magical crypto bits work
like they should. I've sent an email to the chairs saying as much, as well.

  -- Justin
Post by Justas Janauskas
Hello,
Sorry if this is not the right group to send this message; I am new here.
I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.
I made a small program to test correctness of an example and it shows
https://gist.github.com/3263677
I have also implemented an example from previous draft 00, section 1.2
https://gist.github.com/3263765
Thank you,
Justas Janauskas
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Hannes Tschofenig
2012-08-08 16:24:33 UTC
Permalink
Hi Justas,

thanks for sending your feedback to the list.

There is indeed currently no editor for the document. That is, however, not the problem.
The problem, as discussed on the list and also at the last IETF meeting, is that we do not yet know what type of security properties we want. The MAC draft may or may not provide the type of protection we want.

For that reason we first have to figure out what problem we want to solve before we jump into the details of fixing some minor errors.

Ciao
Hannes
Thanks Justas. The MAC document is currently without an editor within the WG, so this is the best place to record the error.
A wider note to the WG: I wouldn't mind taking over editorship of the MAC token document so long as I could get a co-editor with enough cryptographic expertise to make sure all the magical crypto bits work like they should. I've sent an email to the chairs saying as much, as well.
-- Justin
Post by Justas Janauskas
Hello,
Sorry if this is not the right group to send this message; I am new here.
I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.
I made a small program to test correctness of an example and it shows
https://gist.github.com/3263677
I have also implemented an example from previous draft 00, section 1.2
https://gist.github.com/3263765
Thank you,
Justas Janauskas
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Phil Hunt
2012-08-08 16:53:33 UTC
Permalink
I have promised to put together a summary of the discussion presented in vancouver meeting.

Unfortunately it may take a few weeks as i am away for another week and a half.

Phil
Post by Hannes Tschofenig
Hi Justas,
thanks for sending your feedback to the list.
There is indeed currently no editor for the document. That is, however, not the problem.
The problem, as discussed on the list and also at the last IETF meeting, is that we do not yet know what type of security properties we want. The MAC draft may or may not provide the type of protection we want.
For that reason we first have to figure out what problem we want to solve before we jump into the details of fixing some minor errors.
Ciao
Hannes
Thanks Justas. The MAC document is currently without an editor within the WG, so this is the best place to record the error.
A wider note to the WG: I wouldn't mind taking over editorship of the MAC token document so long as I could get a co-editor with enough cryptographic expertise to make sure all the magical crypto bits work like they should. I've sent an email to the chairs saying as much, as well.
-- Justin
Post by Justas Janauskas
Hello,
Sorry if this is not the right group to send this message; I am new here.
I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.
I made a small program to test correctness of an example and it shows
https://gist.github.com/3263677
I have also implemented an example from previous draft 00, section 1.2
https://gist.github.com/3263765
Thank you,
Justas Janauskas
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Justin Richer
2012-08-08 20:59:48 UTC
Permalink
I believe that there's value in per-message signing completely apart
from the channel level encryption. MAC tokens let us do this with a
per-token secret using a pattern very well established in OAuth1. I'm
sorry that I wasn't at the Vancouver meeting to voice this opinion, for
what it's worth.

-- Justin
Post by Hannes Tschofenig
Hi Justas,
thanks for sending your feedback to the list.
There is indeed currently no editor for the document. That is, however, not the problem.
The problem, as discussed on the list and also at the last IETF meeting, is that we do not yet know what type of security properties we want. The MAC draft may or may not provide the type of protection we want.
For that reason we first have to figure out what problem we want to solve before we jump into the details of fixing some minor errors.
Ciao
Hannes
Thanks Justas. The MAC document is currently without an editor within the WG, so this is the best place to record the error.
A wider note to the WG: I wouldn't mind taking over editorship of the MAC token document so long as I could get a co-editor with enough cryptographic expertise to make sure all the magical crypto bits work like they should. I've sent an email to the chairs saying as much, as well.
-- Justin
Post by Justas Janauskas
Hello,
Sorry if this is not the right group to send this message; I am new here.
I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.
I made a small program to test correctness of an example and it shows
https://gist.github.com/3263677
I have also implemented an example from previous draft 00, section 1.2
https://gist.github.com/3263765
Thank you,
Justas Janauskas
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
John Bradley
2012-08-08 21:21:52 UTC
Permalink
We did discuss per message signing in Vancouver.

The idea is to get agreement on the threats we are trying to mitigate, then decide on the mechanisms.

Per message signing will likely still be one of the mechanisms.

The chair will need to decide if we start fresh and copy the parts of MAC that are needed or try and continue the existing MAC draft.

John B.
I believe that there's value in per-message signing completely apart from the channel level encryption. MAC tokens let us do this with a per-token secret using a pattern very well established in OAuth1. I'm sorry that I wasn't at the Vancouver meeting to voice this opinion, for what it's worth.
-- Justin
Post by Hannes Tschofenig
Hi Justas,
thanks for sending your feedback to the list.
There is indeed currently no editor for the document. That is, however, not the problem.
The problem, as discussed on the list and also at the last IETF meeting, is that we do not yet know what type of security properties we want. The MAC draft may or may not provide the type of protection we want.
For that reason we first have to figure out what problem we want to solve before we jump into the details of fixing some minor errors.
Ciao
Hannes
Thanks Justas. The MAC document is currently without an editor within the WG, so this is the best place to record the error.
A wider note to the WG: I wouldn't mind taking over editorship of the MAC token document so long as I could get a co-editor with enough cryptographic expertise to make sure all the magical crypto bits work like they should. I've sent an email to the chairs saying as much, as well.
-- Justin
Post by Justas Janauskas
Hello,
Sorry if this is not the right group to send this message; I am new here.
I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.
I made a small program to test correctness of an example and it shows
https://gist.github.com/3263677
I have also implemented an example from previous draft 00, section 1.2
https://gist.github.com/3263765
Thank you,
Justas Janauskas
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Justin Richer
2012-08-09 14:41:28 UTC
Permalink
OK, that's fair. I just don't want process to get in the way of progress.

-- Justin
Post by John Bradley
We did discuss per message signing in Vancouver.
The idea is to get agreement on the threats we are trying to mitigate, then decide on the mechanisms.
Per message signing will likely still be one of the mechanisms.
The chair will need to decide if we start fresh and copy the parts of MAC that are needed or try and continue the existing MAC draft.
John B.
I believe that there's value in per-message signing completely apart from the channel level encryption. MAC tokens let us do this with a per-token secret using a pattern very well established in OAuth1. I'm sorry that I wasn't at the Vancouver meeting to voice this opinion, for what it's worth.
-- Justin
Post by Hannes Tschofenig
Hi Justas,
thanks for sending your feedback to the list.
There is indeed currently no editor for the document. That is, however, not the problem.
The problem, as discussed on the list and also at the last IETF meeting, is that we do not yet know what type of security properties we want. The MAC draft may or may not provide the type of protection we want.
For that reason we first have to figure out what problem we want to solve before we jump into the details of fixing some minor errors.
Ciao
Hannes
Thanks Justas. The MAC document is currently without an editor within the WG, so this is the best place to record the error.
A wider note to the WG: I wouldn't mind taking over editorship of the MAC token document so long as I could get a co-editor with enough cryptographic expertise to make sure all the magical crypto bits work like they should. I've sent an email to the chairs saying as much, as well.
-- Justin
Post by Justas Janauskas
Hello,
Sorry if this is not the right group to send this message; I am new here.
I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.
I made a small program to test correctness of an example and it shows
https://gist.github.com/3263677
I have also implemented an example from previous draft 00, section 1.2
https://gist.github.com/3263765
Thank you,
Justas Janauskas
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
William Mills
2012-08-09 16:52:55 UTC
Permalink
I find the idea of starting from scratch frustrating.  MAC solves a set of specific problems and has a well defined use case.  It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.

I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.

-bill
Post by John Bradley
We did discuss per message signing in Vancouver.
The idea is to get agreement on the threats we are trying to mitigate, then decide on the mechanisms.
Per message signing will likely still be one of the mechanisms.
The chair will need to decide if we start fresh and copy the parts of MAC that are needed or try and continue the existing MAC draft.
John B.
I believe that there's value in per-message signing completely apart from the channel level encryption. MAC tokens let us do this with a per-token secret using a pattern very well established in OAuth1. I'm sorry that I wasn't at the Vancouver meeting to voice this opinion, for what it's worth.
-- Justin
Post by Hannes Tschofenig
Hi Justas,
thanks for sending your feedback to the list.
There is indeed currently no editor for the document. That is, however, not the problem.
The problem, as discussed on the list and also at the last IETF meeting, is that we do not yet know what type of security properties we want. The MAC draft may or may not provide the type of protection we want.
For that reason we first have to figure out what problem we want to solve before we jump into the details of fixing some minor errors.
Ciao
Hannes
Thanks Justas. The MAC document is currently without an editor within the WG, so this is the best place to record the error.
A wider note to the WG: I wouldn't mind taking over editorship of the MAC token document so long as I could get a co-editor with enough cryptographic expertise to make sure all the magical crypto bits work like they should. I've sent an email to the chairs saying as much, as well.
-- Justin
Post by Justas Janauskas
Hello,
Sorry if this is not the right group to send this message; I am new here.
I believe there is mistake in calculated request MAC presented in
"draft-ietf-oauth-v2-http-mac-01" example, section 1.1.
I made a small program to test correctness of an example and it shows
https://gist.github.com/3263677
I have also implemented an example from previous draft 00, section 1.2
https://gist.github.com/3263765
Thank you,
Justas Janauskas
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Dick Hardt
2012-08-09 17:27:27 UTC
Permalink
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.

For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.

Just my $.02

-- Dick
William Mills
2012-08-09 17:53:43 UTC
Permalink
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.


________________________________
From: Dick Hardt <***@gmail.com>
To: William Mills <***@yahoo.com>
Cc: "***@ietf.org" <***@ietf.org>
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01




On Aug 9, 2012, at 9:52 AM, William Mills wrote:

I find the idea of starting from scratch frustrating.  MAC solves a set of specific problems and has a well defined use case.  It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
Post by William Mills
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. 

For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.

Just my $.02

-- Dick  
Tom Brown
2012-08-09 17:57:58 UTC
Permalink
also, the oauth 2 abstract says the following so it seems confusing that
oauth 1 is the proposed solution for mac:

This
specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849 <http://tools.ietf.org/html/rfc5849>.
Post by William Mills
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are
libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model
and will provide for a single codepath for sites that want to use both
Bearer and MAC.
------------------------------
*Sent:* Thursday, August 9, 2012 10:27 AM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of
specific problems and has a well defined use case. It's symmetric key
based which doesn't work for some folks, and the question is do we try to
develop something that supports both PK and SK, or finish the SK use case
and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is
*VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if
I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
John Bradley
2012-08-09 18:26:05 UTC
Permalink
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.

The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.

Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.

People are welcome to contribute to the use-case document.

Part of the problem with MAC has been that people could never agree on what it was protecting against.

I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.


John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Stephen Farrell
2012-08-09 18:29:11 UTC
Permalink
Post by John Bradley
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Just to clarify: I don't care if its documented in an I-D,
a tune you whistle, or a bunch of emails.

I do agree with what Hannes was saying in Vancouver: that
the WG need to figure out what you want and document that
however the chairs figure is best.

S
Post by John Bradley
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
prateek mishra
2012-08-09 18:29:31 UTC
Permalink
+1

finishing a draft for historical reasons without the full context of HoK
use-cases and identified threats concerns me
Post by John Bradley
In Vancouver the question was asked about the future of the MAC spec
due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the
use-cases we are trying to address before deciding on progressing MAC
or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver
discussion and we are going to work on the use-case/problem
description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on
what it was protecting against.
I think there is general agreement that one or more proof mechanisms
are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
Post by William Mills
MAC fixes the signing problems encountered in OAuth 1.0a, yes there
are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2
auth model and will provide for a single codepath for sites that want
to use both Bearer and MAC.
------------------------------------------------------------------------
*Sent:* Thursday, August 9, 2012 10:27 AM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a
set of specific problems and has a well defined use case. It's
symmetric key based which doesn't work for some folks, and the
question is do we try to develop something that supports both PK and
SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which
is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted
JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
William Mills
2012-08-09 18:43:39 UTC
Permalink
OK, I'll play and start documenting the use cases.  

Use case #1: Secure authentication in plain text connections:

Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections.  HTTP cookies and their ilk are replayable credentials and do not satisfy this need.   the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.

-bill


________________________________
From: John Bradley <***@ve7jtb.com>
To: William Mills <***@yahoo.com>
Cc: Dick Hardt <***@gmail.com>; "***@ietf.org" <***@ietf.org>
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01


In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.

The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.

Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.

People are welcome to contribute to the use-case document.

Part of the problem with MAC has been that people could never agree on what it was protecting against.  

I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored. 


John B.
 

On 2012-08-09, at 1:53 PM, William Mills wrote:

MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Post by Justas Janauskas
________________________________
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating.  MAC solves a set of specific problems and has a well defined use case.  It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
Post by William Mills
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. 
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick  
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Justin Richer
2012-08-09 19:37:09 UTC
Permalink
Use case #2: signature protection over plain HTTP parameters

MAC gives us message-level signing in a way that doesn't require all the
parameters to be packed into an extra structure, like JWT/SAML do. TLS
gives no application-layer verification of integrity of parameters, nor
does it give you the ability to know who presented those parameters
(unless you're doing mutual TLS, which nobody does). MAC gives you a
fairly simple way to protect all parameters on a call to the resource
server while still keeping all of those parameters in their native HTTP
forms.


Use case #3: generic signed HTTP fetch (not directly addressed by MAC
spec as of today)

Sometimes you want to create a URL with one service, fix all of the
parameters in that URL, and protect those parameters with a signature.
Then that URL can be passed to an untrusted service who cannot modify
any portion of it. Nor can they re-use the signature portion to protect
different parameters. We do this today with a 2-legged OAuth signature
across a service URL. The "Client" generates the signed URLs and passes
them to a user agent which actually does the fetch to the service.


-- Justin
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or
need the overhead of encrypted connections. HTTP cookies and their
ilk are replayable credentials and do not satisfy this need. the MAC
scheme using signed HTTP authorization credentials offer the
capability to securely authorize a transaction, can offer integrity
protection on all or part of an HTTP request, and can provide replay
protection.
-bill
------------------------------------------------------------------------
*Sent:* Thursday, August 9, 2012 11:26 AM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec
due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the
use-cases we are trying to address before deciding on progressing MAC
or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver
discussion and we are going to work on the use-case/problem
description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on
what it was protecting against.
I think there is general agreement that one or more proof mechanisms
are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
Post by William Mills
MAC fixes the signing problems encountered in OAuth 1.0a, yes there
are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2
auth model and will provide for a single codepath for sites that want
to use both Bearer and MAC.
------------------------------------------------------------------------
*Sent:* Thursday, August 9, 2012 10:27 AM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a
set of specific problems and has a well defined use case. It's
symmetric key based which doesn't work for some folks, and the
question is do we try to develop something that supports both PK and
SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which
is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted
JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
George Fletcher
2012-08-09 20:32:10 UTC
Permalink
+1

We've supported #3 for quite some time in our public APIs that pre-date
OAuth.

Thanks,
George
Post by Justin Richer
Use case #2: signature protection over plain HTTP parameters
MAC gives us message-level signing in a way that doesn't require all
the parameters to be packed into an extra structure, like JWT/SAML do.
TLS gives no application-layer verification of integrity of
parameters, nor does it give you the ability to know who presented
those parameters (unless you're doing mutual TLS, which nobody does).
MAC gives you a fairly simple way to protect all parameters on a call
to the resource server while still keeping all of those parameters in
their native HTTP forms.
Use case #3: generic signed HTTP fetch (not directly addressed by MAC
spec as of today)
Sometimes you want to create a URL with one service, fix all of the
parameters in that URL, and protect those parameters with a signature.
Then that URL can be passed to an untrusted service who cannot modify
any portion of it. Nor can they re-use the signature portion to
protect different parameters. We do this today with a 2-legged OAuth
signature across a service URL. The "Client" generates the signed URLs
and passes them to a user agent which actually does the fetch to the
service.
-- Justin
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want
or need the overhead of encrypted connections. HTTP cookies and
their ilk are replayable credentials and do not satisfy this need.
the MAC scheme using signed HTTP authorization credentials offer the
capability to securely authorize a transaction, can offer integrity
protection on all or part of an HTTP request, and can provide replay
protection.
-bill
------------------------------------------------------------------------
*Sent:* Thursday, August 9, 2012 11:26 AM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec
due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the
use-cases we are trying to address before deciding on progressing MAC
or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver
discussion and we are going to work on the use-case/problem
description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree
on what it was protecting against.
I think there is general agreement that one or more proof mechanisms
are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
Post by William Mills
MAC fixes the signing problems encountered in OAuth 1.0a, yes there
are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2
auth model and will provide for a single codepath for sites that
want to use both Bearer and MAC.
------------------------------------------------------------------------
*Sent:* Thursday, August 9, 2012 10:27 AM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a
set of specific problems and has a well defined use case. It's
symmetric key based which doesn't work for some folks, and the
question is do we try to develop something that supports both PK
and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which
is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted
JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
David Waite
2012-08-09 23:02:06 UTC
Permalink
For #1:
Does the use of plain HTTP to talk to protected resources provide significant value when using an AS that requires HTTPS? Or am I misunderstanding, and this use case would also include new modes for non-TLS communication with the AS?

For #2:
Would the signature protection just cover HTTP parameters, or would it extend to covering any request data, such as a PUT binary file? Would the integrity protection only cover requests, or would you also have integrity protection of the response?

-DW
Post by Justin Richer
Use case #2: signature protection over plain HTTP parameters
MAC gives us message-level signing in a way that doesn't require all the parameters to be packed into an extra structure, like JWT/SAML do. TLS gives no application-layer verification of integrity of parameters, nor does it give you the ability to know who presented those parameters (unless you're doing mutual TLS, which nobody does). MAC gives you a fairly simple way to protect all parameters on a call to the resource server while still keeping all of those parameters in their native HTTP forms.
Use case #3: generic signed HTTP fetch (not directly addressed by MAC spec as of today)
Sometimes you want to create a URL with one service, fix all of the parameters in that URL, and protect those parameters with a signature. Then that URL can be passed to an untrusted service who cannot modify any portion of it. Nor can they re-use the signature portion to protect different parameters. We do this today with a 2-legged OAuth signature across a service URL. The "Client" generates the signed URLs and passes them to a user agent which actually does the fetch to the service.
-- Justin
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
William Mills
2012-08-09 23:19:51 UTC
Permalink
AS would still be required to be HTTPS as per the spec.


________________________________
From: David Waite <***@alkaline-solutions.com>
To: ***@ietf.org
Sent: Thursday, August 9, 2012 4:02 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01


For #1:
Does the use of plain HTTP to talk to protected resources provide significant value when using an AS that requires HTTPS? Or am I misunderstanding, and this use case would also include new modes for non-TLS communication with the AS?

For #2:
Would the signature protection just cover HTTP parameters, or would it extend to covering any request data, such as a PUT binary file? Would the integrity protection only cover requests, or would you also have integrity protection of the response?

-DW

On Aug 9, 2012, at 1:37 PM, Justin Richer <***@mitre.org> wrote:

Use case #2: signature protection over plain HTTP parameters
Post by Justin Richer
MAC gives us message-level signing in a way that doesn't require
all the parameters to be packed into an extra structure, like
JWT/SAML do. TLS gives no application-layer verification of
integrity of parameters, nor does it give you the ability to know
who presented those parameters (unless you're doing mutual TLS,
which nobody does). MAC gives you a fairly simple way to protect
all parameters on a call to the resource server while still
keeping all of those parameters in their native HTTP forms.
Post by Justin Richer
Use case #3: generic signed HTTP fetch (not directly addressed by MAC spec as of today)
Sometimes you want to create a URL with one service, fix all of
the parameters in that URL, and protect those parameters with a
signature. Then that URL can be passed to an untrusted service who
cannot modify any portion of it. Nor can they re-use the signature
portion to protect different parameters. We do this today with a
2-legged OAuth signature across a service URL. The "Client"
generates the signed URLs and passes them to a user agent which
actually does the fetch to the service.
Post by Justin Richer
 -- Justin
OK, I'll play and start documenting the use cases.  
Post by William Mills
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections.  HTTP cookies and their ilk are replayable credentials and do not satisfy this need.   the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
________________________________
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.  
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored. 
John B.
 
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Post by Justas Janauskas
________________________________
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating.  MAC solves a set of specific problems and has a well defined use case.  It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
Post by William Mills
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. 
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick  
_______________________________________________
Post by Justin Richer
Post by William Mills
Post by Justas Janauskas
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list ***@ietf.org https://www.ietf.org/mailman/listinfo/oauth
John Bradley
2012-08-10 03:47:54 UTC
Permalink
Bill,

I seem to recall in Paris that client misconfiguration of TLS was a concern.

In MAC the token secret is delivered with the token based on server TLS and HTTP basic authentication.

If this is OK and we trust the client to do TLS server certificate verification correctly that needs to go in as one of our base assumptions. Or conversely additional protection of the token endpoint needs to be considered for key distribution.

John B.
Post by William Mills
AS would still be required to be HTTPS as per the spec.
Sent: Thursday, August 9, 2012 4:02 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Does the use of plain HTTP to talk to protected resources provide significant value when using an AS that requires HTTPS? Or am I misunderstanding, and this use case would also include new modes for non-TLS communication with the AS?
Would the signature protection just cover HTTP parameters, or would it extend to covering any request data, such as a PUT binary file? Would the integrity protection only cover requests, or would you also have integrity protection of the response?
-DW
Post by Justin Richer
Use case #2: signature protection over plain HTTP parameters
MAC gives us message-level signing in a way that doesn't require all the parameters to be packed into an extra structure, like JWT/SAML do. TLS gives no application-layer verification of integrity of parameters, nor does it give you the ability to know who presented those parameters (unless you're doing mutual TLS, which nobody does). MAC gives you a fairly simple way to protect all parameters on a call to the resource server while still keeping all of those parameters in their native HTTP forms.
Use case #3: generic signed HTTP fetch (not directly addressed by MAC spec as of today)
Sometimes you want to create a URL with one service, fix all of the parameters in that URL, and protect those parameters with a signature. Then that URL can be passed to an untrusted service who cannot modify any portion of it. Nor can they re-use the signature portion to protect different parameters. We do this today with a 2-legged OAuth signature across a service URL. The "Client" generates the signed URLs and passes them to a user agent which actually does the fetch to the service.
-- Justin
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
William Mills
2012-08-10 14:36:11 UTC
Permalink
I would say that's true in theory, but practically speaking it's not gonna happen.  You're stating we need to come up with a better method for public key than we have now for this to be widely adopted, and I don't think that's reasonable.

If we're gonna improve on the current PKI that is SSL certificates we should do that separately.


________________________________
From: John Bradley <***@ve7jtb.com>
To: William Mills <***@yahoo.com>
Cc: David Waite <***@alkaline-solutions.com>; "***@ietf.org" <***@ietf.org>
Sent: Thursday, August 9, 2012 8:47 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01


Bill,

I seem to recall in Paris that client misconfiguration of TLS was a concern.

In MAC the token secret is delivered with the token based on server TLS and HTTP basic authentication.

If this is OK and we trust the client to do TLS server certificate verification correctly that needs to go in as one of our base assumptions.  Or conversely additional protection of the token endpoint needs to be considered for key distribution.

John B.

On 2012-08-09, at 7:19 PM, William Mills wrote:

AS would still be required to be HTTPS as per the spec.
Post by Justas Janauskas
________________________________
Sent: Thursday, August 9, 2012 4:02 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Does the use of plain HTTP to talk to protected resources provide significant value when using an AS that requires HTTPS? Or am I misunderstanding, and this use case would also include new modes for non-TLS communication with the AS?
Would the signature protection just cover HTTP parameters, or would it extend to covering any request data, such as a PUT binary file? Would the integrity protection only cover requests, or would you also have integrity protection of the response?
-DW
Use case #2: signature protection over plain HTTP parameters
Post by Justin Richer
MAC gives us message-level signing in a way that doesn't require
all the parameters to be packed into an extra structure, like
JWT/SAML do. TLS gives no application-layer verification of
integrity of parameters, nor does it give you the ability to know
who presented those parameters (unless you're doing mutual TLS,
which nobody does). MAC gives you a fairly simple way to protect
all parameters on a call to the resource server while still
keeping all of those parameters in their native HTTP forms.
Post by Justas Janauskas
Post by Justin Richer
Use case #3: generic signed HTTP fetch (not directly addressed by MAC spec as of today)
Sometimes you want to create a URL with one service, fix all of
the parameters in that URL, and protect those parameters with a
signature. Then that URL can be passed to an untrusted service who
cannot modify any portion of it. Nor can they re-use the signature
portion to protect different parameters. We do this today with a
2-legged OAuth signature across a service URL. The "Client"
generates the signed URLs and passes them to a user agent which
actually does the fetch to the service.
Post by Justas Janauskas
Post by Justin Richer
 -- Justin
OK, I'll play and start documenting the use cases.  
Post by William Mills
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections.  HTTP cookies and their ilk are replayable credentials and do not satisfy this need.   the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
________________________________
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.  
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored. 
John B.
 
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Post by Justas Janauskas
________________________________
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating.  MAC solves a set of specific problems and has a well defined use case.  It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
Post by William Mills
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. 
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick  
_______________________________________________
Post by Justas Janauskas
Post by Justin Richer
Post by William Mills
Post by Justas Janauskas
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list ***@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
Post by Justas Janauskas
Post by Justin Richer
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Richer, Justin P.
2012-08-10 14:38:53 UTC
Permalink
Agreed w/Bill, let's not unnecessarily conflate the problem space.

-- Justin

On Aug 10, 2012, at 10:36 AM, William Mills wrote:

I would say that's true in theory, but practically speaking it's not gonna happen. You're stating we need to come up with a better method for public key than we have now for this to be widely adopted, and I don't think that's reasonable.

If we're gonna improve on the current PKI that is SSL certificates we should do that separately.

________________________________
From: John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>>
To: William Mills <***@yahoo.com<mailto:***@yahoo.com>>
Cc: David Waite <***@alkaline-solutions.com<mailto:***@alkaline-solutions.com>>; "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Sent: Thursday, August 9, 2012 8:47 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Bill,

I seem to recall in Paris that client misconfiguration of TLS was a concern.

In MAC the token secret is delivered with the token based on server TLS and HTTP basic authentication.

If this is OK and we trust the client to do TLS server certificate verification correctly that needs to go in as one of our base assumptions. Or conversely additional protection of the token endpoint needs to be considered for key distribution.

John B.
On 2012-08-09, at 7:19 PM, William Mills wrote:

AS would still be required to be HTTPS as per the spec.

________________________________
From: David Waite <***@alkaline-solutions.com<mailto:***@alkaline-solutions.com>>
To: ***@ietf.org<mailto:***@ietf.org>
Sent: Thursday, August 9, 2012 4:02 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

For #1:
Does the use of plain HTTP to talk to protected resources provide significant value when using an AS that requires HTTPS? Or am I misunderstanding, and this use case would also include new modes for non-TLS communication with the AS?

For #2:
Would the signature protection just cover HTTP parameters, or would it extend to covering any request data, such as a PUT binary file? Would the integrity protection only cover requests, or would you also have integrity protection of the response?

-DW

On Aug 9, 2012, at 1:37 PM, Justin Richer <***@mitre.org<mailto:***@mitre.org>> wrote:

Use case #2: signature protection over plain HTTP parameters

MAC gives us message-level signing in a way that doesn't require all the parameters to be packed into an extra structure, like JWT/SAML do. TLS gives no application-layer verification of integrity of parameters, nor does it give you the ability to know who presented those parameters (unless you're doing mutual TLS, which nobody does). MAC gives you a fairly simple way to protect all parameters on a call to the resource server while still keeping all of those parameters in their native HTTP forms.


Use case #3: generic signed HTTP fetch (not directly addressed by MAC spec as of today)

Sometimes you want to create a URL with one service, fix all of the parameters in that URL, and protect those parameters with a signature. Then that URL can be passed to an untrusted service who cannot modify any portion of it. Nor can they re-use the signature portion to protect different parameters. We do this today with a 2-legged OAuth signature across a service URL. The "Client" generates the signed URLs and passes them to a user agent which actually does the fetch to the service.


-- Justin

On 08/09/2012 02:43 PM, William Mills wrote:
OK, I'll play and start documenting the use cases.

Use case #1: Secure authentication in plain text connections:

Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.

-bill

________________________________
From: John Bradley <***@ve7jtb.com><mailto:***@ve7jtb.com>
To: William Mills <***@yahoo.com><mailto:***@yahoo.com>
Cc: Dick Hardt <***@gmail.com><mailto:***@gmail.com>; "***@ietf.org"<mailto:***@ietf.org> <***@ietf.org><mailto:***@ietf.org>
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.

The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.

Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.

People are welcome to contribute to the use-case document.

Part of the problem with MAC has been that people could never agree on what it was protecting against.

I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.


John B.

On 2012-08-09, at 1:53 PM, William Mills wrote:

MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.

________________________________
From: Dick Hardt <***@gmail.com<mailto:***@gmail.com>>
To: William Mills <***@yahoo.com<mailto:***@yahoo.com>>
Cc: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01


On Aug 9, 2012, at 9:52 AM, William Mills wrote:

I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.

I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.

Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.

For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.

Just my $.02

-- Dick



_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth






_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
John Bradley
2012-08-10 15:09:10 UTC
Permalink
No I wasn't talking about changing TLS. I think the TLS threat has been expressed more as people who turn verification in the client rather than any failure of the TLS protocol or certificates.

The question I was trying to get at was if any of the message signing was intended to protect against clients misconfiguring TLS or Man in the middle attacking communications with the RS or token server.

Part of the reason behind MAC has been expressed as concern that Server TLS doesn't prevent tokens from being intercepted and replayed sufficiently.

Where TLS is used if we believe clients are properly implemented what is the signing getting us.

I think sessions without TLS and TLS terminated on the firewall need to be supported, but there the threat is clearer.

John
Post by Richer, Justin P.
I would say that's true in theory, but practically speaking it's not gonna happen. You're stating we need to come up with a better method for public key than we have now for this to be widely adopted, and I don't think that's reasonable.
If we're gonna improve on the current PKI that is SSL certificates we should do that separately.
Sent: Thursday, August 9, 2012 8:47 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Bill,
I seem to recall in Paris that client misconfiguration of TLS was a concern.
In MAC the token secret is delivered with the token based on server TLS and HTTP basic authentication.
If this is OK and we trust the client to do TLS server certificate verification correctly that needs to go in as one of our base assumptions. Or conversely additional protection of the token endpoint needs to be considered for key distribution.
John B.
Post by William Mills
AS would still be required to be HTTPS as per the spec.
Sent: Thursday, August 9, 2012 4:02 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Does the use of plain HTTP to talk to protected resources provide significant value when using an AS that requires HTTPS? Or am I misunderstanding, and this use case would also include new modes for non-TLS communication with the AS?
Would the signature protection just cover HTTP parameters, or would it extend to covering any request data, such as a PUT binary file? Would the integrity protection only cover requests, or would you also have integrity protection of the response?
-DW
Post by Justin Richer
Use case #2: signature protection over plain HTTP parameters
MAC gives us message-level signing in a way that doesn't require all the parameters to be packed into an extra structure, like JWT/SAML do. TLS gives no application-layer verification of integrity of parameters, nor does it give you the ability to know who presented those parameters (unless you're doing mutual TLS, which nobody does). MAC gives you a fairly simple way to protect all parameters on a call to the resource server while still keeping all of those parameters in their native HTTP forms.
Use case #3: generic signed HTTP fetch (not directly addressed by MAC spec as of today)
Sometimes you want to create a URL with one service, fix all of the parameters in that URL, and protect those parameters with a signature. Then that URL can be passed to an untrusted service who cannot modify any portion of it. Nor can they re-use the signature portion to protect different parameters. We do this today with a 2-legged OAuth signature across a service URL. The "Client" generates the signed URLs and passes them to a user agent which actually does the fetch to the service.
-- Justin
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
William Mills
2012-08-10 15:59:27 UTC
Permalink
It's not intended to address anything in TLS other than the fact that we have real use cases where TLS isn't in play.  



________________________________
From: John Bradley <***@ve7jtb.com>
To: William Mills <***@yahoo.com>
Cc: David Waite <***@alkaline-solutions.com>; "***@ietf.org" <***@ietf.org>
Sent: Friday, August 10, 2012 8:09 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01


No I wasn't talking about changing TLS.  I think the TLS threat has been expressed more as people who turn verification in the client rather than any failure of the TLS protocol or certificates.

The question I was trying to get at was if any of the message signing was intended to protect against clients misconfiguring TLS or Man in the middle attacking communications with the RS or token server.

Part of the reason behind MAC has been expressed as concern that Server TLS doesn't prevent tokens from being intercepted and replayed sufficiently.   

Where TLS is used if we believe clients are properly implemented what is the signing getting us.

I think sessions without TLS and TLS terminated on the firewall need to be supported, but there the threat is clearer.

John


On 2012-08-10, at 10:36 AM, William Mills wrote:

I would say that's true in theory, but practically speaking it's not gonna happen.  You're stating we need to come up with a better method for public key than we have now for this to be widely adopted, and I don't think that's reasonable.
Post by William Mills
If we're gonna improve on the current PKI that is SSL certificates we should do that separately.
________________________________
Sent: Thursday, August 9, 2012 8:47 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Bill,
I seem to recall in Paris that client misconfiguration of TLS was a concern.
In MAC the token secret is delivered with the token based on server TLS and HTTP basic authentication.
If this is OK and we trust the client to do TLS server certificate verification correctly that needs to go in as one of our base assumptions.  Or conversely additional protection of the token endpoint needs to be considered for key distribution.
John B.
AS would still be required to be HTTPS as per the spec.
Post by Justas Janauskas
________________________________
Sent: Thursday, August 9, 2012 4:02 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Does the use of plain HTTP to talk to protected resources provide significant value when using an AS that requires HTTPS? Or am I misunderstanding, and this use case would also include new modes for non-TLS communication with the AS?
Would the signature protection just cover HTTP parameters, or would it extend to covering any request data, such as a PUT binary file? Would the integrity protection only cover requests, or would you also have integrity protection of the response?
-DW
Use case #2: signature protection over plain HTTP parameters
Post by Justin Richer
MAC gives us message-level signing in a way that doesn't require
all the parameters to be packed into an extra structure, like
JWT/SAML do. TLS gives no application-layer verification of
integrity of parameters, nor does it give you the ability to know
who presented those parameters (unless you're doing mutual TLS,
which nobody does). MAC gives you a fairly simple way to protect
all parameters on a call to the resource server while still
keeping all of those parameters in their native HTTP forms.
Post by William Mills
Post by Justas Janauskas
Post by Justin Richer
Use case #3: generic signed HTTP fetch (not directly addressed by MAC spec as of today)
Sometimes you want to create a URL with one service, fix all of
the parameters in that URL, and protect those parameters with a
signature. Then that URL can be passed to an untrusted service who
cannot modify any portion of it. Nor can they re-use the signature
portion to protect different parameters. We do this today with a
2-legged OAuth signature across a service URL. The "Client"
generates the signed URLs and passes them to a user agent which
actually does the fetch to the service.
Post by William Mills
Post by Justas Janauskas
Post by Justin Richer
 -- Justin
OK, I'll play and start documenting the use cases.  
Post by William Mills
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections.  HTTP cookies and their ilk are replayable credentials and do not satisfy this need.   the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
________________________________
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.  
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored. 
John B.
 
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Post by Justas Janauskas
________________________________
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating.  MAC solves a set of specific problems and has a well defined use case.  It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
Post by William Mills
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. 
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick  
_______________________________________________
Post by William Mills
Post by Justas Janauskas
Post by Justin Richer
Post by William Mills
Post by Justas Janauskas
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list ***@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
Post by William Mills
Post by Justas Janauskas
Post by Justin Richer
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Justin Richer
2012-08-10 16:07:35 UTC
Permalink
Specifically, there are cases where it "isn't in play at all" and cases
where it "isn't in play end to end".

-- Justin
Post by William Mills
It's not intended to address anything in TLS other than the fact that
we have real use cases where TLS isn't in play.
------------------------------------------------------------------------
*Sent:* Friday, August 10, 2012 8:09 AM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
No I wasn't talking about changing TLS. I think the TLS threat has
been expressed more as people who turn verification in the client
rather than any failure of the TLS protocol or certificates.
The question I was trying to get at was if any of the message signing
was intended to protect against clients misconfiguring TLS or Man in
the middle attacking communications with the RS or token server.
Part of the reason behind MAC has been expressed as concern that
Server TLS doesn't prevent tokens from being intercepted and replayed
sufficiently.
Where TLS is used if we believe clients are properly implemented what
is the signing getting us.
I think sessions without TLS and TLS terminated on the firewall need
to be supported, but there the threat is clearer.
John
Post by William Mills
I would say that's true in theory, but practically speaking it's not
gonna happen. You're stating we need to come up with a better method
for public key than we have now for this to be widely adopted, and I
don't think that's reasonable.
If we're gonna improve on the current PKI that is SSL certificates we
should do that separately.
------------------------------------------------------------------------
*Sent:* Thursday, August 9, 2012 8:47 PM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Bill,
I seem to recall in Paris that client misconfiguration of TLS was a concern.
In MAC the token secret is delivered with the token based on server
TLS and HTTP basic authentication.
If this is OK and we trust the client to do TLS server certificate
verification correctly that needs to go in as one of our base
assumptions. Or conversely additional protection of the token
endpoint needs to be considered for key distribution.
John B.
Post by William Mills
AS would still be required to be HTTPS as per the spec.
------------------------------------------------------------------------
*Sent:* Thursday, August 9, 2012 4:02 PM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Does the use of plain HTTP to talk to protected resources provide
significant value when using an AS that requires HTTPS? Or am I
misunderstanding, and this use case would also include new modes for
non-TLS communication with the AS?
Would the signature protection just cover HTTP parameters, or would
it extend to covering any request data, such as a PUT binary
file? Would the integrity protection only cover requests, or would
you also have integrity protection of the response?
-DW
Post by Justin Richer
Use case #2: signature protection over plain HTTP parameters
MAC gives us message-level signing in a way that doesn't require
all the parameters to be packed into an extra structure, like
JWT/SAML do. TLS gives no application-layer verification of
integrity of parameters, nor does it give you the ability to know
who presented those parameters (unless you're doing mutual TLS,
which nobody does). MAC gives you a fairly simple way to protect
all parameters on a call to the resource server while still keeping
all of those parameters in their native HTTP forms.
Use case #3: generic signed HTTP fetch (not directly addressed by
MAC spec as of today)
Sometimes you want to create a URL with one service, fix all of the
parameters in that URL, and protect those parameters with a
signature. Then that URL can be passed to an untrusted service who
cannot modify any portion of it. Nor can they re-use the signature
portion to protect different parameters. We do this today with a
2-legged OAuth signature across a service URL. The "Client"
generates the signed URLs and passes them to a user agent which
actually does the fetch to the service.
-- Justin
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not
want or need the overhead of encrypted connections. HTTP cookies
and their ilk are replayable credentials and do not satisfy this
need. the MAC scheme using signed HTTP authorization credentials
offer the capability to securely authorize a transaction, can
offer integrity protection on all or part of an HTTP request, and
can provide replay protection.
-bill
------------------------------------------------------------------------
*Sent:* Thursday, August 9, 2012 11:26 AM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC
spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the
use-cases we are trying to address before deciding on progressing
MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver
discussion and we are going to work on the use-case/problem
description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never
agree on what it was protecting against.
I think there is general agreement that one or more proof
mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
Post by William Mills
MAC fixes the signing problems encountered in OAuth 1.0a, yes
there are libraries out there for OAuth 1.0a. MAC fits in to the
OAuth 2 auth model and will provide for a single codepath for
sites that want to use both Bearer and MAC.
------------------------------------------------------------------------
*Sent:* Thursday, August 9, 2012 10:27 AM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC
solves a set of specific problems and has a well defined use
case. It's symmetric key based which doesn't work for some
folks, and the question is do we try to develop something that
supports both PK and SK, or finish the SK use case and then work
on a PK based draft.
I think it's better to leave them separate and finish out MAC
which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or
encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Hannes Tschofenig
2012-08-10 07:05:23 UTC
Permalink
Hi Justin,

thanks for the feedback. Comments below.
Post by Justin Richer
Use case #2: signature protection over plain HTTP parameters
MAC gives us message-level signing in a way that doesn't require all the parameters to be packed into an extra structure, like JWT/SAML do. TLS gives no application-layer verification of integrity of parameters, nor does it give you the ability to know who presented those parameters (unless you're doing mutual TLS, which nobody does). MAC gives you a fairly simple way to protect all parameters on a call to the resource server while still keeping all of those parameters in their native HTTP forms.
First, we have to assume as a starting point that we have bearer. So, assuming that there is actually plain HTTP for the communication between the client and the resource server does not exist.

TLS does indeed not give the ability for the resource server to know who the client is. Client authentication would do that.
Btw, the MAC draft does not allow the client to be authenticated.

The MAC token does not protect all the parameters in the message. In fact, it protects only very, very few!

TLS is an application layer protocol (it runs on top of TCP) and protects the integrity and the confidentiality of the parameters in an end-to-end fashion. However, as others have noted the end on the server side may be a load balancer in case a system administrator has intentionally decided to terminate all secure traffic there. Saying that MAC would then be "more e2e" may be true unless the administrator has again decided to terminate it also at the load balancer (which may not be completely unlikely).
Post by Justin Richer
Use case #3: generic signed HTTP fetch (not directly addressed by MAC spec as of today)
Sometimes you want to create a URL with one service, fix all of the parameters in that URL, and protect those parameters with a signature. Then that URL can be passed to an untrusted service who cannot modify any portion of it. Nor can they re-use the signature portion to protect different parameters. We do this today with a 2-legged OAuth signature across a service URL. The "Client" generates the signed URLs and passes them to a user agent which actually does the fetch to the service.
(I personally would have even liked to get rid of the 2-legged OAuth use cases).

I think that this use case is again a bit different from what we have been talking about so far. Maybe you want to compile an Internet draft so that we have more details to assess the security properties better.

Ciao
Hannes
Post by Justin Richer
-- Justin
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Richer, Justin P.
2012-08-10 14:38:03 UTC
Permalink
Post by Hannes Tschofenig
Hi Justin,
thanks for the feedback. Comments below.
Sure thing, I think that use cases are very important to enumerate. I think the fact that several people in the WG are coming forward and saying "Yes I have use cases for this" is very telling that this is an important problem to solve.
Post by Hannes Tschofenig
Post by Justin Richer
Use case #2: signature protection over plain HTTP parameters
MAC gives us message-level signing in a way that doesn't require all the parameters to be packed into an extra structure, like JWT/SAML do. TLS gives no application-layer verification of integrity of parameters, nor does it give you the ability to know who presented those parameters (unless you're doing mutual TLS, which nobody does). MAC gives you a fairly simple way to protect all parameters on a call to the resource server while still keeping all of those parameters in their native HTTP forms.
First, we have to assume as a starting point that we have bearer. So, assuming that there is actually plain HTTP for the communication between the client and the resource server does not exist.
I'm confused here -- what exactly do you mean by this statement?
Post by Hannes Tschofenig
TLS does indeed not give the ability for the resource server to know who the client is. Client authentication would do that.
Btw, the MAC draft does not allow the client to be authenticated.
TLS mutual auth doesn't let you express the full context that comes with an OAuth token.
Post by Hannes Tschofenig
The MAC token does not protect all the parameters in the message. In fact, it protects only very, very few!
Which is why we need to update and fix it! I never said that MAC was *done*, just that it's a pretty good starting point and we shouldn't ignore it. This is the point that Bill was making, too, if I read it right.
Post by Hannes Tschofenig
TLS is an application layer protocol (it runs on top of TCP) and protects the integrity and the confidentiality of the parameters in an end-to-end fashion. However, as others have noted the end on the server side may be a load balancer in case a system administrator has intentionally decided to terminate all secure traffic there. Saying that MAC would then be "more e2e" may be true unless the administrator has again decided to terminate it also at the load balancer (which may not be completely unlikely).
Load balancers and performance are a red herring and are distracting this conversation. There are other reasons to have message-level signing. Not everything is a single point-to-point HTTP transaction that TLS assumes. In such multi-hop scenarios, TLS can protect things on the wire but not within the components that can read and forward it, such as in use case #3 below.
Post by Hannes Tschofenig
Post by Justin Richer
Use case #3: generic signed HTTP fetch (not directly addressed by MAC spec as of today)
Sometimes you want to create a URL with one service, fix all of the parameters in that URL, and protect those parameters with a signature. Then that URL can be passed to an untrusted service who cannot modify any portion of it. Nor can they re-use the signature portion to protect different parameters. We do this today with a 2-legged OAuth signature across a service URL. The "Client" generates the signed URLs and passes them to a user agent which actually does the fetch to the service.
(I personally would have even liked to get rid of the 2-legged OAuth use cases).
There are many, many important use cases that use the two legged pattern, and many, many people use them today in both OAuth1 (which never specified them) and OAuth2 (which finally embraced them as valid). They're not going away.
Post by Hannes Tschofenig
I think that this use case is again a bit different from what we have been talking about so far. Maybe you want to compile an Internet draft so that we have more details to assess the security properties better.
Yes it is, but it can be covered by the same solution set with some minor changes. Like I said, it's not directly covered by the MAC draft right now.



I have other scenarios that have message-level signing as a stated requirement, full stop. I'd like to be able to use OAuth machinery to fulfill this.

-- Justin
Post by Hannes Tschofenig
Ciao
Hannes
Post by Justin Richer
-- Justin
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Hannes Tschofenig
2012-08-10 07:01:30 UTC
Permalink
Hi Bill,

thanks for the feedback. Let's have a look at this use case:

You need to provide me a bit more information regarding your use case. Could you please explain

1) Who is authenticated to whom?
2) What plaintext connection are you talking about?
3) What is the problem with encrypted connections? Is this again the "TLS has so bad performance" argument?
4) Since you are talking about cookies and making them more secure are you trying to come up with a general solution to better cookie security - a topic others are working on as well.
5) What is the threat you are concerned about?

Ciao
Hannes

PS: I would heavily argue against standardize a security mechanism that offers weaker protection than bearer when the entire argument has always been "Bearer is so insecure and we need something stronger."
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Richer, Justin P.
2012-08-10 14:41:05 UTC
Permalink
What about security in depth? Signing + TLS is more secure than either alone, isn't it?

-- Justin
Post by Hannes Tschofenig
Hi Bill,
You need to provide me a bit more information regarding your use case. Could you please explain
1) Who is authenticated to whom?
2) What plaintext connection are you talking about?
3) What is the problem with encrypted connections? Is this again the "TLS has so bad performance" argument?
4) Since you are talking about cookies and making them more secure are you trying to come up with a general solution to better cookie security - a topic others are working on as well.
5) What is the threat you are concerned about?
Ciao
Hannes
PS: I would heavily argue against standardize a security mechanism that offers weaker protection than bearer when the entire argument has always been "Bearer is so insecure and we need something stronger."
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Rob Richards
2012-08-10 15:00:33 UTC
Permalink
I think you nailed it which that statement. Up until now it as been back
and forth about one or the other. Personally I prefer to used layered
security and not relying on a single point of attack. It's unrealistic
to say everyone is going to want/need/be able to use (take your pick)
signed/encrypted JWT. MAC at least offers an alternative, less
complicated solution.

Rob
Post by Richer, Justin P.
What about security in depth? Signing + TLS is more secure than either alone, isn't it?
-- Justin
Post by Hannes Tschofenig
Hi Bill,
You need to provide me a bit more information regarding your use case. Could you please explain
1) Who is authenticated to whom?
2) What plaintext connection are you talking about?
3) What is the problem with encrypted connections? Is this again the "TLS has so bad performance" argument?
4) Since you are talking about cookies and making them more secure are you trying to come up with a general solution to better cookie security - a topic others are working on as well.
5) What is the threat you are concerned about?
Ciao
Hannes
PS: I would heavily argue against standardize a security mechanism that offers weaker protection than bearer when the entire argument has always been "Bearer is so insecure and we need something stronger."
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Dick Hardt
2012-08-10 16:18:30 UTC
Permalink
As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying.

Given that, there is also a clear need for signing an HTTP(S) request as some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't want to use bearer tokens.

I never followed what MAC solved that OAuth 1.0A did not solve. Would someone elaborate? We do have an RFC for signing requests, there are lots of libraries already. Why the desire to reinvent OAuth 1.0A?

-- Dick
I think you nailed it which that statement. Up until now it as been back and forth about one or the other. Personally I prefer to used layered security and not relying on a single point of attack. It's unrealistic to say everyone is going to want/need/be able to use (take your pick) signed/encrypted JWT. MAC at least offers an alternative, less complicated solution.
Rob
Post by Richer, Justin P.
What about security in depth? Signing + TLS is more secure than either alone, isn't it?
-- Justin
Post by Hannes Tschofenig
Hi Bill,
You need to provide me a bit more information regarding your use case. Could you please explain
1) Who is authenticated to whom?
2) What plaintext connection are you talking about?
3) What is the problem with encrypted connections? Is this again the "TLS has so bad performance" argument?
4) Since you are talking about cookies and making them more secure are you trying to come up with a general solution to better cookie security - a topic others are working on as well.
5) What is the threat you are concerned about?
Ciao
Hannes
PS: I would heavily argue against standardize a security mechanism that offers weaker protection than bearer when the entire argument has always been "Bearer is so insecure and we need something stronger."
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Justin Richer
2012-08-10 16:25:18 UTC
Permalink
The reason is simple: to benefit from the rest of the improvements in
the OAuth2 framework. These are just the ones off the top of my head:

1) Multiple means for getting a token (all the flows are now available)
2) No request tokens
3) No reliance on per-client secrets (though, addendum, I think the MAC
spec should be augmented to use them if present)
4) Ability to integrate with many different extensions to OAuth2, both
now and in the future

-- Justin
Post by Dick Hardt
As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying.
Given that, there is also a clear need for signing an HTTP(S) request as some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't want to use bearer tokens.
I never followed what MAC solved that OAuth 1.0A did not solve. Would someone elaborate? We do have an RFC for signing requests, there are lots of libraries already. Why the desire to reinvent OAuth 1.0A?
-- Dick
I think you nailed it which that statement. Up until now it as been back and forth about one or the other. Personally I prefer to used layered security and not relying on a single point of attack. It's unrealistic to say everyone is going to want/need/be able to use (take your pick) signed/encrypted JWT. MAC at least offers an alternative, less complicated solution.
Rob
Post by Richer, Justin P.
What about security in depth? Signing + TLS is more secure than either alone, isn't it?
-- Justin
Post by Hannes Tschofenig
Hi Bill,
You need to provide me a bit more information regarding your use case. Could you please explain
1) Who is authenticated to whom?
2) What plaintext connection are you talking about?
3) What is the problem with encrypted connections? Is this again the "TLS has so bad performance" argument?
4) Since you are talking about cookies and making them more secure are you trying to come up with a general solution to better cookie security - a topic others are working on as well.
5) What is the threat you are concerned about?
Ciao
Hannes
PS: I would heavily argue against standardize a security mechanism that offers weaker protection than bearer when the entire argument has always been "Bearer is so insecure and we need something stronger."
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Dick Hardt
2012-08-10 16:43:53 UTC
Permalink
Those reasons make sense to me, thanks for enumerating.
Post by Justin Richer
1) Multiple means for getting a token (all the flows are now available)
2) No request tokens
3) No reliance on per-client secrets (though, addendum, I think the MAC spec should be augmented to use them if present)
4) Ability to integrate with many different extensions to OAuth2, both now and in the future
-- Justin
Post by Dick Hardt
As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying.
Given that, there is also a clear need for signing an HTTP(S) request as some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't want to use bearer tokens.
I never followed what MAC solved that OAuth 1.0A did not solve. Would someone elaborate? We do have an RFC for signing requests, there are lots of libraries already. Why the desire to reinvent OAuth 1.0A?
-- Dick
I think you nailed it which that statement. Up until now it as been back and forth about one or the other. Personally I prefer to used layered security and not relying on a single point of attack. It's unrealistic to say everyone is going to want/need/be able to use (take your pick) signed/encrypted JWT. MAC at least offers an alternative, less complicated solution.
Rob
Post by Richer, Justin P.
What about security in depth? Signing + TLS is more secure than either alone, isn't it?
-- Justin
Post by Hannes Tschofenig
Hi Bill,
You need to provide me a bit more information regarding your use case. Could you please explain
1) Who is authenticated to whom?
2) What plaintext connection are you talking about?
3) What is the problem with encrypted connections? Is this again the "TLS has so bad performance" argument?
4) Since you are talking about cookies and making them more secure are you trying to come up with a general solution to better cookie security - a topic others are working on as well.
5) What is the threat you are concerned about?
Ciao
Hannes
PS: I would heavily argue against standardize a security mechanism that offers weaker protection than bearer when the entire argument has always been "Bearer is so insecure and we need something stronger."
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
William Mills
2012-08-10 16:57:35 UTC
Permalink
In no particular order:

As I said before, and many have said before me, a major issue with OAuth 1.0a has always been the signing process.  Yes there are libraries.  MAC was begun before there were a significant number of libraries.  You also have to process/parse the post body for oauth_ variables if you're really going to be compliant, and people don't like that much.

OAuth 1.0a has signing with a client secret, but that secret is managed out of band.  MAC+Oauth 2 has the client secret issued with the token.  This is fundamentally different and far more suitable for the consumer/end user client case.  1.0a is structured more for a 3 party model, where the secret is used to authenticate the 3rd party, out of band secret management isn't as much of a problem there.  

1.0a is just clumsy to implement for consumer/end user clients, the OAuth 2 model is far cleaner, and in the end in 1.0a  the secret ends up not a secret anymore.  It ends up being the equivalent of bearer tokens in security.   This is because, I think,  fundamentally the client secret is tied in through the token request/auth stuff and then also in the access to the protected resource.  

We could theoretically have something very similar to the way MAC tokens would be fetched in OAuth 2, and use that secret with OAuth 1.0a signing to access the protected resource.  That would work, but it would be kinda gross.

-bill







________________________________
From: Dick Hardt <***@gmail.com>
To: Rob Richards <***@cdatazone.org>
Cc: "***@ietf.org" <***@ietf.org>
Sent: Friday, August 10, 2012 9:18 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying.

Given that, there is also a clear need for signing an HTTP(S) request as some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't want to use bearer tokens.

I never followed what MAC solved that OAuth 1.0A did not solve. Would someone elaborate? We do have an RFC for signing requests, there are lots of libraries already. Why the desire to reinvent OAuth 1.0A?

-- Dick
I think you nailed it which that statement. Up until now it as been back and forth about one or the other. Personally I prefer to used layered security and not relying on a single point of attack. It's unrealistic to say everyone is going to want/need/be able to use (take your pick) signed/encrypted JWT. MAC at least offers an alternative, less complicated solution.
Rob
Post by Richer, Justin P.
What about security in depth? Signing + TLS is more secure than either alone, isn't it?
  -- Justin
Post by Hannes Tschofenig
Hi Bill,
You need to provide me a bit more information regarding your use case. Could you please explain
1) Who is authenticated to whom?
2) What plaintext connection are you talking about?
3) What is the problem with encrypted connections? Is this again the "TLS has so bad performance" argument?
4) Since you are talking about cookies and making them more secure are you trying to come up with a general solution to better cookie security - a topic others are working on as well.
5) What is the threat you are concerned about?
Ciao
Hannes
PS: I would heavily argue against standardize a security mechanism that offers weaker protection than bearer when the entire argument has always been "Bearer is so insecure and we need something stronger."
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections.  HTTP cookies and their ilk are replayable credentials and do not satisfy this need.  the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating.  MAC solves a set of specific problems and has a well defined use case.  It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Sergey Beryozkin
2012-09-03 14:25:17 UTC
Permalink
Post by Dick Hardt
As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying.
Given that, there is also a clear need for signing an HTTP(S) request as some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't want to use bearer tokens.
I never followed what MAC solved that OAuth 1.0A did not solve. Would someone elaborate? We do have an RFC for signing requests, there are lots of libraries already. Why the desire to reinvent OAuth 1.0A?
I see OAuth 1.0A users starting asking why to move to OAuth 2.0,
especially now that there's a bit of concern there for some of the users
due to the recent critique of OAuth 2.0.

IMHO one of the best reasons for completing the MAC spec is to help
OAuth 1.0 users with migrating to OAuth 2.0 as the code flow + MAC is
indeed very similar to OAuth 1.0A; having different OAuth camps out
there won't be great

Thanks, Sergey
Post by Dick Hardt
-- Dick
I think you nailed it which that statement. Up until now it as been back and forth about one or the other. Personally I prefer to used layered security and not relying on a single point of attack. It's unrealistic to say everyone is going to want/need/be able to use (take your pick) signed/encrypted JWT. MAC at least offers an alternative, less complicated solution.
Rob
Post by Richer, Justin P.
What about security in depth? Signing + TLS is more secure than either alone, isn't it?
-- Justin
Post by Hannes Tschofenig
Hi Bill,
You need to provide me a bit more information regarding your use case. Could you please explain
1) Who is authenticated to whom?
2) What plaintext connection are you talking about?
3) What is the problem with encrypted connections? Is this again the "TLS has so bad performance" argument?
4) Since you are talking about cookies and making them more secure are you trying to come up with a general solution to better cookie security - a topic others are working on as well.
5) What is the threat you are concerned about?
Ciao
Hannes
PS: I would heavily argue against standardize a security mechanism that offers weaker protection than bearer when the entire argument has always been "Bearer is so insecure and we need something stronger."
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against.
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Justin Richer
2012-09-04 14:28:14 UTC
Permalink
Post by Sergey Beryozkin
Post by Dick Hardt
As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying.
Given that, there is also a clear need for signing an HTTP(S) request
as some sites are choosing OAuth 1.0A over OAuth 2.0 because they
don't want to use bearer tokens.
I never followed what MAC solved that OAuth 1.0A did not solve. Would
someone elaborate? We do have an RFC for signing requests, there are
lots of libraries already. Why the desire to reinvent OAuth 1.0A?
I see OAuth 1.0A users starting asking why to move to OAuth 2.0,
especially now that there's a bit of concern there for some of the
users due to the recent critique of OAuth 2.0.
IMHO one of the best reasons for completing the MAC spec is to help
OAuth 1.0 users with migrating to OAuth 2.0 as the code flow + MAC is
indeed very similar to OAuth 1.0A; having different OAuth camps out
there won't be great
Very much agreed! It's a glaring hole in the capabilities of OAuth 2.0,
and one I'd like to see patched, and soon.

-- Justin
Post by Sergey Beryozkin
Thanks, Sergey
Post by Dick Hardt
-- Dick
Post by Rob Richards
I think you nailed it which that statement. Up until now it as been
back and forth about one or the other. Personally I prefer to used
layered security and not relying on a single point of attack. It's
unrealistic to say everyone is going to want/need/be able to use
(take your pick) signed/encrypted JWT. MAC at least offers an
alternative, less complicated solution.
Rob
Post by Richer, Justin P.
What about security in depth? Signing + TLS is more secure than
either alone, isn't it?
-- Justin
Post by Hannes Tschofenig
Hi Bill,
You need to provide me a bit more information regarding your use
case. Could you please explain
1) Who is authenticated to whom?
2) What plaintext connection are you talking about?
3) What is the problem with encrypted connections? Is this again
the "TLS has so bad performance" argument?
4) Since you are talking about cookies and making them more secure
are you trying to come up with a general solution to better cookie
security - a topic others are working on as well.
5) What is the threat you are concerned about?
Ciao
Hannes
PS: I would heavily argue against standardize a security mechanism
that offers weaker protection than bearer when the entire argument
has always been "Bearer is so insecure and we need something
stronger."
Post by William Mills
OK, I'll play and start documenting the use cases.
Some applications need a secure form authorization, but do not
want or need the overhead of encrypted connections. HTTP cookies
and their ilk are replayable credentials and do not satisfy this
need. the MAC scheme using signed HTTP authorization
credentials offer the capability to securely authorize a
transaction, can offer integrity protection on all or part of an
HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC
spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the
use-cases we are trying to address before deciding on progressing
MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver
discussion and we are going to work on the use-case/problem
description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never
agree on what it was protecting against.
I think there is general agreement that one or more proof
mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
Post by William Mills
MAC fixes the signing problems encountered in OAuth 1.0a, yes
there are libraries out there for OAuth 1.0a. MAC fits in to
the OAuth 2 auth model and will provide for a single codepath
for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC
solves a set of specific problems and has a well defined use
case. It's symmetric key based which doesn't work for some
folks, and the question is do we try to develop something that
supports both PK and SK, or finish the SK use case and then
work on a PK based draft.
I think it's better to leave them separate and finish out MAC
which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or
encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
William Mills
2012-08-10 14:42:42 UTC
Permalink
________________________________
From: Hannes Tschofenig <***@gmx.net>
To: William Mills <***@yahoo.com>
Cc: Hannes Tschofenig <***@gmx.net>; John Bradley <***@ve7jtb.com>; "***@ietf.org" <***@ietf.org>
Sent: Friday, August 10, 2012 12:01 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

Hi Bill,

thanks for the feedback. Let's have a look at this use case:

You need to provide me a bit more information regarding your use case. Could you please explain

1) Who is authenticated to whom?


wjm> the client is authenticated to the server.

2) What plaintext connection are you talking about? 

wjm> generally an HTTP connection to a webservice

3) What is the problem with encrypted connections? Is this again the "TLS has so bad performance" argument? 


wjm>  Yes, annoying but true.  This may change, but we do business with enough folks that refuse SSL that this is a real problem.

4) Since you are talking about cookies and making them more secure are you trying to come up with a general solution to better cookie security - a topic others are working on as well. 

wjm>  No, I'm pointing out the problems with a simple replayable credential like cookies as a comparison.

5) What is the threat you are concerned about?

wjm> The vulnerability of plaintext connections: theft of credentials and tampering. 

Ciao
Hannes

PS: I would heavily argue against standardize a security mechanism that offers weaker protection than bearer when the entire argument has always been "Bearer is so insecure and we need something stronger."
OK, I'll play and start documenting the use cases. 
Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections.  HTTP cookies and their ilk are replayable credentials and do not satisfy this need.   the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection.
-bill
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document.
Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP.
People are welcome to contribute to the use-case document.
Part of the problem with MAC has been that people could never agree on what it was protecting against. 
I think there is general agreement that one or more proof mechanisms are required for access tokens.
Security for the token endpoint also cannot be ignored.
John B.
 
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating.  MAC solves a set of specific problems and has a well defined use case.  It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick 
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Sergey Beryozkin
2012-08-09 19:22:47 UTC
Permalink
Post by William Mills
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are
libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth
model
I work on the framework which already supports MAC (with major thanks to
a user contribution). I'm not too worried that MAC draft may not end up
being a final specification - because OAuth2.0 allows for different
token types and whatever MAC already offers can be 'packaged' as a
custom token if really needed, moreover, experienced users may help to
fix whatever bugs that still remain in the draft; I'm very new to this
list and effort, but I think I can get that it offers a (symmetric)
holder-of-key support - and as such it's good for the framework because
there will be users which will like working with MAC.

Having said that, I'd really like to give some support to the idea of
completing the draft - to minimize the proliferation of custom token
types which may end up trying to solve the same problem
Post by William Mills
and will provide for a single codepath for sites that want to use
both Bearer and MAC.
+1

Sergey
Post by William Mills
------------------------------------------------------------------------
*Sent:* Thursday, August 9, 2012 10:27 AM
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set
of specific problems and has a well defined use case. It's symmetric
key based which doesn't work for some folks, and the question is do we
try to develop something that supports both PK and SK, or finish the
SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is
*VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT
if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Dick Hardt
2012-08-09 19:48:11 UTC
Permalink
As an implementer, I have an app that accesses 10 different resources. Some are OAuth 1.0A, some are a variant of OAuth 2. All have a slightly different code path since each resource is its own beautiful snowflake. I did not use any libraries for OAuth 2. Supporting MAC would give me yet another library to integrate with.

I'd be interested in what signing problems OAuth 1.0A has. I have my own list of how writing to OAuth 1.0A is hard.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 Aa
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
Justin Richer
2012-08-09 20:08:35 UTC
Permalink
With MAC, you should be able to re-use about 80-90% of your existing
codepath that's in place for Bearer, simplifying the setup below.

I would figure that the "variant of OAuth2" issue is a red herring
because not everyone out there is fully spec compliant. If they were,
you wouldn't have so many beautiful snowflakes.

-- Justin
Post by Dick Hardt
As an implementer, I have an app that accesses 10 different resources.
Some are OAuth 1.0A, some are a variant of OAuth 2. All have a
slightly different code path since each resource is its own beautiful
snowflake. I did not use any libraries for OAuth 2. Supporting MAC
would give me yet another library to integrate with.
I'd be interested in what signing problems OAuth 1.0A has. I have my
own list of how writing to OAuth 1.0A is hard.
Post by William Mills
MAC fixes the signing problems encountered in OAuth 1.0a, yes there
are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2
auth model and will provide for a single codepath for sites that want
to use both Bearer and MAC.
------------------------------------------------------------------------
*Sent:* Thursday, August 9, 2012 10:27 Aa
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a
set of specific problems and has a well defined use case. It's
symmetric key based which doesn't work for some folks, and the
question is do we try to develop something that supports both PK and
SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which
is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted
JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Dick Hardt
2012-08-09 22:47:36 UTC
Permalink
With MAC, you should be able to re-use about 80-90% of your existing codepath that's in place for Bearer, simplifying the setup below.
That makes no sense, I would be adding MAC to the sites that support MAC in addition to OAuth 1.0A or OAuth 2.0
I would figure that the "variant of OAuth2" issue is a red herring because not everyone out there is fully spec compliant. If they were, you wouldn't have so many beautiful snowflakes.
Being consistent in the spec would help, but likely would just give me snowflakes that look more like each other.

There are many aspects of the OAuth dance that are implementation dependent and it is simpler to just have a separate method for each one that deals with those unique characteristics. Note this is not theory, this is practice. Different modules was not an issue. Not having to use a library to sign requests and being able to use CURL or a browser to see what a request returned had a HUGE productivity gain for OAuth 2.0 implementations over OAuth 1.0A implemetations.
-- Justin
Post by Dick Hardt
As an implementer, I have an app that accesses 10 different resources. Some are OAuth 1.0A, some are a variant of OAuth 2. All have a slightly different code path since each resource is its own beautiful snowflake. I did not use any libraries for OAuth 2. Supporting MAC would give me yet another library to integrate with.
I'd be interested in what signing problems OAuth 1.0A has. I have my own list of how writing to OAuth 1.0A is hard.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 Aa
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Justin Richer
2012-08-10 16:28:07 UTC
Permalink
Post by Dick Hardt
Post by Justin Richer
With MAC, you should be able to re-use about 80-90% of your existing
codepath that's in place for Bearer, simplifying the setup below.
That makes no sense, I would be adding MAC to the sites that support
MAC in addition to OAuth 1.0A or OAuth 2.0
You get to re-use all of the code for OAuth2 for issuing tokens (from
server side) and requesting tokens (from client side). Apart from
parsing the JSON value that's returned from the token endpoint (and you
are using a generic parser there, right?), nothing changes here. The
part where you *use* the token to access a protected resource (client),
or *validate* a request to a protected resource (server) changes
significantly, yes. But that's only a small part of the process.
Post by Dick Hardt
Post by Justin Richer
I would figure that the "variant of OAuth2" issue is a red herring
because not everyone out there is fully spec compliant. If they were,
you wouldn't have so many beautiful snowflakes.
Being consistent in the spec would help, but likely would just give me
snowflakes that look more like each other.
There are many aspects of the OAuth dance that are implementation
dependent and it is simpler to just have a separate method for each
one that deals with those unique characteristics. Note this is not
theory, this is practice. Different modules was not an issue. Not
having to use a library to sign requests and being able to use CURL or
a browser to see what a request returned had a HUGE productivity gain
for OAuth 2.0 implementations over OAuth 1.0A implemetations.
Post by Justin Richer
-- Justin
Post by Dick Hardt
As an implementer, I have an app that accesses 10 different
resources. Some are OAuth 1.0A, some are a variant of OAuth 2. All
have a slightly different code path since each resource is its own
beautiful snowflake. I did not use any libraries for OAuth 2.
Supporting MAC would give me yet another library to integrate with.
I'd be interested in what signing problems OAuth 1.0A has. I have my
own list of how writing to OAuth 1.0A is hard.
Post by William Mills
MAC fixes the signing problems encountered in OAuth 1.0a, yes there
are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2
auth model and will provide for a single codepath for sites that
want to use both Bearer and MAC.
------------------------------------------------------------------------
*Sent:* Thursday, August 9, 2012 10:27 Aa
*Subject:* Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves
a set of specific problems and has a well defined use case. It's
symmetric key based which doesn't work for some folks, and the
question is do we try to develop something that supports both PK
and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC
which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted
JWT if I need holder of key.
Just my $.02
-- Dick
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Dick Hardt
2012-08-10 16:48:59 UTC
Permalink
Post by Dick Hardt
With MAC, you should be able to re-use about 80-90% of your existing codepath that's in place for Bearer, simplifying the setup below.
That makes no sense, I would be adding MAC to the sites that support MAC in addition to OAuth 1.0A or OAuth 2.0
You get to re-use all of the code for OAuth2 for issuing tokens (from server side) and requesting tokens (from client side). Apart from parsing the JSON value that's returned from the token endpoint (and you are using a generic parser there, right?), nothing changes here. The part where you *use* the token to access a protected resource (client), or *validate* a request to a protected resource (server) changes significantly, yes. But that's only a small part of the process.
That makes sense, sorry I was not clear on what I said did not make sense, which was "simplifying the setup below"

As a client developer, adding MAC to the mix *increases* my code base as it is yet another protocol to understand and implement against. OAuth 1.0A and OAuth 2.0 bearer are not going to go away.

-- Dick
Justin Richer
2012-08-10 17:02:42 UTC
Permalink
Post by Dick Hardt
Post by Justin Richer
Post by Dick Hardt
Post by Justin Richer
With MAC, you should be able to re-use about 80-90% of your
existing codepath that's in place for Bearer, simplifying the setup
below.
That makes no sense, I would be adding MAC to the sites that support
MAC in addition to OAuth 1.0A or OAuth 2.0
You get to re-use all of the code for OAuth2 for issuing tokens (from
server side) and requesting tokens (from client side). Apart from
parsing the JSON value that's returned from the token endpoint (and
you are using a generic parser there, right?), nothing changes here.
The part where you *use* the token to access a protected resource
(client), or *validate* a request to a protected resource (server)
changes significantly, yes. But that's only a small part of the process.
That makes sense, sorry I was not clear on what I said did not make
sense, which was "simplifying the setup below"
As a client developer, adding MAC to the mix *increases* my code base
as it is yet another protocol to understand and implement against.
OAuth 1.0A and OAuth 2.0 bearer are not going to go away.
OK, I follow now. Yes, that's a fair concern for anyone who has to
support multiple protocols that aren't mutually compatible. I'm
personally hoping that OAuth2/MAC will help push out most (if not all)
of the remaining OAuth1 pieces we have here, helping is shut down at
least one of those.

-- Justin
William Mills
2012-08-09 20:47:30 UTC
Permalink
Mostly it's around making sure you get the signature base string constructed right in my experience.


________________________________
From: Dick Hardt <***@gmail.com>
To: William Mills <***@yahoo.com>
Cc: Dick Hardt <***@gmail.com>; "***@ietf.org" <***@ietf.org>
Sent: Thursday, August 9, 2012 12:48 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01


As an implementer, I have an app that accesses 10 different resources. Some are OAuth 1.0A, some are a variant of OAuth 2. All have a slightly different code path since each resource is its own beautiful snowflake. I did not use any libraries for OAuth 2. Supporting MAC would give me yet another library to integrate with.

I'd be interested in what signing problems OAuth 1.0A has. I have my own list of how writing to OAuth 1.0A is hard.



On Aug 9, 2012, at 10:53 AM, William Mills wrote:

MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Post by Justas Janauskas
________________________________
Sent: Thursday, August 9, 2012 10:27 Aa
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating.  MAC solves a set of specific problems and has a well defined use case.  It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
Post by William Mills
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. 
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick  
Dick Hardt
2012-08-09 22:39:50 UTC
Permalink
Yes, sort of.

I blew two days debugging my code accessing Twitter.

We had intermittent failures. It would work for hours, and then fail for hours.

Eventually I noticed that we were calling http://api.twitter.com instead of https://api.twitter.com. Once we changed that it worked fine.
Post by William Mills
Mostly it's around making sure you get the signature base string constructed right in my experience.
Sent: Thursday, August 9, 2012 12:48 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
As an implementer, I have an app that accesses 10 different resources. Some are OAuth 1.0A, some are a variant of OAuth 2. All have a slightly different code path since each resource is its own beautiful snowflake. I did not use any libraries for OAuth 2. Supporting MAC would give me yet another library to integrate with.
I'd be interested in what signing problems OAuth 1.0A has. I have my own list of how writing to OAuth 1.0A is hard.
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC.
Sent: Thursday, August 9, 2012 10:27 Aa
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft.
I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done.
Who is interested in MAC? People can use OAuth 1.0 if they prefer that model.
For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key.
Just my $.02
-- Dick
Loading...