[OAUTH-WG] Pre-IETF 84 versions of JOSE and JWT specifications

[Mike Jones]

I’ve made a minor release of the JSON WEB 
{Signature,Encryption,Key,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) working 
group specifications and the JWS and JWE JSON Serialization (JWS-JS, JWE-JS) 
individual submission specifications in preparation for IETF 84 in Vancouver, 
BC.  These versions incorporate 
feedback from working group members since the major release on July 
6th, and update the lists of open issues in 
preparation for discussions in Vancouver (and on the working group mailing 
lists).

One significant addition is that the JWT and JWE-JS specs both now contain 
complete, testable examples with encrypted results.  No normative changes were 
made.

The working group specifications are available at:

·http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-04

·http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04

·http://tools.ietf.org/html/draft-ietf-jose-json-web-key-04

·http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-04

·http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-02

The individual submission specifications are available at:

·http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-01

·http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-01

The document history entries (also in the specifications) are as follows:

http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-04

  *   Completed JSON Security Considerations section, including considerations 
about rejecting input with duplicate member names.
  *   Completed security considerations on the use of a SHA-1 hash when 
computing x5t (x.509 certificate thumbprint) values.
  *   Refer to the registries as the primary sources of defined values and then 
secondarily reference the sections defining the initial contents of the 
registries.
  *   Normatively reference XML DSIG 2.0 [W3C.CR‑xmldsig‑core2‑20120124] for 
its security considerations.
  *   Added this language to Registration Templates: "This name is case 
sensitive. Names that match other registered names in a case insensitive manner 
SHOULD NOT be accepted."
  *   Reference draft-jones-jose-jws-json-serialization instead of 
draft-jones-json-web-signature-json-serialization.
  *   Described additional open issues.
  *   Applied editorial suggestions.

http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04

  *   Refer to the registries as the primary sources of defined values and then 
secondarily reference the sections defining the initial contents of the 
registries.
  *   Normatively reference XML Encryption 1.1 [W3C.CR‑xmlenc‑core1‑20120313] 
for its security considerations.
  *   Reference draft-jones-jose-jwe-json-serialization instead of 
draft-jones-json-web-encryption-json-serialization.
  *   Described additional open issues.
  *   Applied editorial suggestions.

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-04

  *   Refer to the registries as the primary sources of defined values and then 
secondarily reference the sections defining the initial contents of the 
registries.
  *   Normatively reference XML DSIG 2.0 [W3C.CR‑xmldsig‑core2‑20120124] for 
its security considerations.
  *   Added this language to Registration Templates: "This name is case 
sensitive. Names that match other registered names in a case insensitive manner 
SHOULD NOT be accepted."
  *   Described additional open issues.
  *   Applied editorial suggestions.

http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-04

  *   Added text requiring that any leading zero bytes be retained in base64url 
encoded key value representations for fixed-length values.
  *   Added this language to Registration Templates: "This name is case 
sensitive. Names that match other registered names in a case insensitive manner 
SHOULD NOT be accepted."
  *   Described additional open issues.
  *   Applied editorial suggestions.

http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-02

  *   Added an example of an encrypted JWT.
  *   Added this language to Registration Templates: "This name is case 
sensitive. Names that match other registered names in a case insensitive manner 
SHOULD NOT be accepted."
  *   Applied editorial suggestions.

http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-01

  *   Generalized language to refer to Message Authentication Codes (MACs) 
rather than Hash-based Message Authentication Codes (HMACs).

http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-01

  *   Added a complete JWE-JS example.
  *   Generalized language to refer to Message Authentication Codes (MACs) 
rather than Hash-based Message Authentication Codes (HMACs).

-- Mike


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/list

[OAUTH-WG] High-level observations on HoK Issues

[Phil Hunt]

Some observations about requirements and issues for designing an OAuth HoK 
proposal.  

Note: I have intentionally tried to stay away from specifics like token types, 
encryption types and have only at most delved into asymmetric vs. symmetric 
keys.  I see positives in many combinations for different scenarios.  That 
said, I'm not yet sure that one proposal can meet all high level requirements.

I am happy to present this for discussion at the OAuth WG meeting in Vancouver.

Players at The Party
Most crypto cases discuss scenarios involving a sender and receiver. For these 
scenarios, there may be 3 identities in play.  Plus a 4th during setup.
The client application (that accesses the resource). 
A client applicaiton may have its own client credential (backed by PKI key pair 
or other credential). Many clients may share the same credential so...
Sometimes we are more interested in uniquely identifying an instance of a 
client (if the client keys are not unique).
The resource server being accessed.
Delegation token (access token). An authority granted by an authorization 
server for a client to access on a users behalf
Authorization server (a server that does secure communication with the client 
for the purpose of issuing access tokens and potentially exchanging secrets).

Public vs. Confidential Clients
In OAuth scenarios, there are two sets of broad clients to consider: Public and 
Confidential. Here are some characterizations that occur to me.

Public
In many cases public clients are light weight. While they can do TLS, their 
ability to generate key pairs might be limited. Symmetric keys may be easier?
Public clients generate requests primarily based on user input actions. While 
latency is an issue, overall throughput is low.
A public client typically only has access tokens representing delegated 
authorizations for a single user.
Public clients are difficult to uniquely identify. In OAuth, such clients may 
only be identified by a self asserted client_id which by itself cannot be 
verified.
Confidential
Confidential clients are often web apps that can serve many users and other 
service providers directly.
Confidential clients usually have many access tokens (100s to millions) 
representing delegated authorizations for many many users.
A single confidential client may generate 1000s of requests per second using 
1000s of different access tokens. 
Connection pooling is an important scaling factor.
Confidential clients usually have client credential that can be well protected. 
 It may be reasonable to expect a client to have a private key.
Confidential clients often have unique client credentials (though not 
guaranteed).

Authentication vs. Uniqueness
Typically in HoK the drive is "authentication". I would contend that this isn't 
the case in OAuth. The "authentication" step was already performed in the 
authorization steps (or done externally). In most cases we simply want to 
verify that the client issued a token is the one using an access token. 
In OAuth, client credentials are often shared by multiple client software 
instances.
Many OAuth threats are mitigated when a token or code can be bound to a 
specific "instance" of a client.  
Binding a token to a "client" credential may not be sufficient. Even while a 
strong client authentication credential helps mitigate risk, binding tokens to 
"instances" of clients is better.

TLS vs. Open Channel
There are many cases where transport security may not be needed or not desired. 
Since a particular access token could be used for many things, it is not 
necessarily true that an access token intended for a low-risk service is only 
used at a low-risk service.  
Bearer tokens can be sniffed over open (non-TLS) connections, this poses a 
particular risk for sniffing attacks.
For some applications the oauth token may be more valuable than the resource. 
Some applications may wish to secure only the access token.
TLS One-way provides a way for clients to authenticate the service and to 
secure and protect traffic integrity.
Two-way TLS provides bi-directional authentication but has limited use in 
practice as service providers often terminate TLS at load balancers.  TLS 
channel information may not be available to the web tier.
Their is some discussion that even with TLS, rogue proxies could be used as an 
attack vector. Therefore a secure token is still desirable.
Message vs. Channel HoK
There are three forms of HoK that can be used:
Channel HoK - In channel HoK, the client proves identity as suggested by Hannes 
HoTK draft.
A client HoK channel could be bound to the client or could be bound to a oauth 
authorize token context.
There may  trade-offs in connection pooling for using client bound vs. access 
token bound HoK.
Client bound Keys may be long-lived. Access token keys are shorter lived
Long lived keys should be asymmetric.

Message HoK - In message HoK, a proof contained within the authorization header 
token protects the credential from sniffi

[OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : JSON Web Token (JWT)
Author(s)   : Michael B. Jones
  John Bradley
  Nat Sakimura
Filename: draft-ietf-oauth-json-web-token-02.txt
Pages   : 24
Date: 2012-07-16

Abstract:
   JSON Web Token (JWT) is a means of representing claims to be
   transferred between two parties.  The claims in a JWT are encoded as
   a JavaScript Object Notation (JSON) object that is digitally signed
   or MACed using JSON Web Signature (JWS) and/or encrypted using JSON
   Web Encryption (JWE).

   The suggested pronunciation of JWT is the same as the English word
   "jot".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-02

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-use-cases-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : OAuth Use Cases
Author(s)   : George Fletcher
  Torsten Lodderstedt
  Zachary Zeltsan
Filename: draft-ietf-oauth-use-cases-01.txt
Pages   : 23
Date: 2012-07-16

Abstract:
   This document lists the OAuth use cases.  The provided list is based
   on the Internet Drafts of the OAUTH working group and discussions on
   the group's mailing list.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-use-cases

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-use-cases-01

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-use-cases-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] SASL / OAuth Binding Request: User Field

[Ryan Troll]

I'd like to discuss the possibility of adding a "user" field to the
SASL/OAuth request.  This is based on draft-ietf-kitten-sasl-oauth-00.txt.

*Background*
The contents of this field may be used by the resource provider as a hint
to aid in request routing, and/or data location, without the need
for decrypting the provided access token.  The contents of the user field
is not used to grant access of any kind.


*Proposed Addition*
The text of this addition could look something like this:

Section 3.1 addition / update:

user:  Contains the user ID of the user being authorized

In authorization schemes that use signatures, the client MUST send host,
port number and user key/values, and the server MUST fail authorization
requests requiring signatures that do not have host, port, and user values.


Section 3.2 addition:

If the user field is present, the ID in the user field must match the ID
obtained from the credential for the request to succeed.



*Rationale for Presence of User Field in the Request*
This data is not required by all resource providers, and as such could be a
provider-specific requirement, placed (for example) in the query string.
 By documenting the user field, we encourage resource providers that do
require it to find it in the same location - encouraging inter-operability.

The user identity could be determined via the access token, rather than
requiring it in the request.  However, using the access token to determine
the identity can result in the resource provider decoding the token
multiple times, or making multiple requests to the access provider.  By
pulling this attribute out into the protocol, we may be able to simplify
the resource provider work required when moving to OAuth.


*Rationale for Location of User Field*
This data could be transmitted as part of the path, or a query string
parameter, or in the post body.  This approach, using a header, was
proposed as there are currently no path, query string, or post fields
defined.  Those three locations remain untouched by this proposal.
*
*
*
*
Comments?
-R
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] draft-tschofenig-oauth-hotk-01

[Hannes Tschofenig]

Hi all, 

I had just submitted an updated version of the holder-of-the-key document and 
you can find it here: 
http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01

John, Tony, and Phil joined me as co-authors and the document now also 
describes the symmetric key case (even though I am not entirely convinced about 
it) but there was good discussion feedback on the mailing list about it and so 
it makes sense to illustrate a strawman solution. 

Ciao
Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-v2-30 and draft-ietf-oauth-v2-bearer-22

[Stephen Farrell]

Hi Hannes,

That's great thanks. And thanks all for the good work.

Since there've been a good few changes and a bit of time
has elapsed I'll give the other IESG members who previously
commented on these a few days to check if the changes are
ok, and then I can shoot 'em along.

Cheers,
S.

PS: A few days probably means a week really, since there's
a packed telechat agenda this week of about 500 wonderful
pages of I-D, so I wouldn't expect folks to have much
chance to look at this before Friday;-)

On 07/16/2012 06:39 PM, Hannes Tschofenig wrote:
> Hi Stephen, 
> 
> I had just gotten the confirmation from the authors of draft-ietf-oauth-v2-30 
> and draft-ietf-oauth-v2-bearer-22 that all remaining open issues had been 
> closed. The evaluation record also shows happy IESG members. 
> 
> Please advance the status of these two documents. 
> 
> Ciao
> Hannes
> 
> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] draft-ietf-oauth-v2-30 and draft-ietf-oauth-v2-bearer-22

[Hannes Tschofenig]

Hi Stephen, 

I had just gotten the confirmation from the authors of draft-ietf-oauth-v2-30 
and draft-ietf-oauth-v2-bearer-22 that all remaining open issues had been 
closed. The evaluation record also shows happy IESG members. 

Please advance the status of these two documents. 

Ciao
Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-urn-sub-ns-06.txt

[Brian Campbell]

Draft -06 of An IETF URN Sub-Namespace for OAuth has been published.
The only changes in this draft are to address editorial comments made
in the Gen-ART LC Review at
http://www.ietf.org/mail-archive/web/gen-art/current/msg07576.html -
the comment was a typo (from should be form) rather than a missing
word.

Thanks,
Brian


-- Forwarded message --
From:  
Date: Mon, Jul 16, 2012 at 11:41 AM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-06.txt
To: i-d-annou...@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working
Group of the IETF.

Title   : An IETF URN Sub-Namespace for OAuth
Author(s)   : Brian Campbell
  Hannes Tschofenig
Filename: draft-ietf-oauth-urn-sub-ns-06.txt
Pages   : 7
Date: 2012-07-16

Abstract:
   This document establishes an IETF URN Sub-namespace for use with
   OAuth related specifications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-06

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-urn-sub-ns-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : An IETF URN Sub-Namespace for OAuth
Author(s)   : Brian Campbell
  Hannes Tschofenig
Filename: draft-ietf-oauth-urn-sub-ns-06.txt
Pages   : 7
Date: 2012-07-16

Abstract:
   This document establishes an IETF URN Sub-namespace for use with
   OAuth related specifications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-06

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-urn-sub-ns-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Design Team Conference Call - Monday, 16th July (1pm EST)

[Mike Jones]

Started, and ready for people to call in at the top of the hour...

I recommend that people join at https://www3.gotomeeting.com/join/695548174 a 
few minutes early, since there may be some download time when you start 
GotoMeeting.

-- Mike

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat 
Sakimura
Sent: Monday, July 16, 2012 9:39 AM
To: Hannes Tschofenig
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Design Team Conference Call - Monday, 16th July (1pm 
EST)

Mike, please start the bridge.
I am bound to the Cloud Identity Summit.

On Fri, Jul 13, 2012 at 4:43 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

for our conference call next week Nat offered his conference bridge (since we 
had some problems with Google+).

Date: 16hh July 2012 (Monday)
Time: 1pm EDT

Agenda: We will do a status check on these documents:
*draft-ietf-oauth-v2
*draft-ietf-oauth-v2-bearer
*draft-ietf-oauth-v2-threatmodel
*draft-ietf-oauth-urn-sub-ns
*draft-ietf-oauth-assertions

I expect this to be a short call since we are just making sure that all drafts 
are submitted prior to the deadline.

Conference Bridge:
https://www3.gotomeeting.com/join/695548174

Participants are advised to try the link before the call because it is going to 
download and install the software.

Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in 
using your telephone.

Dial +1 (773) 897-3000
Access Code: 695-548-174
Audio PIN: Shown after joining the meeting

Meeting ID: 695-548-174

Nat or Mike will be the host for the call and they will start it.

Ciao
Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Design Team Conference Call - Monday, 16th July (1pm EST)

[Nat Sakimura]

Mike, please start the bridge.
I am bound to the Cloud Identity Summit.

On Fri, Jul 13, 2012 at 4:43 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:

> Hi all,
>
> for our conference call next week Nat offered his conference bridge (since
> we had some problems with Google+).
>
> Date: 16hh July 2012 (Monday)
> Time: 1pm EDT
>
> Agenda: We will do a status check on these documents:
> *draft-ietf-oauth-v2
> *draft-ietf-oauth-v2-bearer
> *draft-ietf-oauth-v2-threatmodel
> *draft-ietf-oauth-urn-sub-ns
> *draft-ietf-oauth-assertions
>
> I expect this to be a short call since we are just making sure that all
> drafts are submitted prior to the deadline.
>
> Conference Bridge:
> https://www3.gotomeeting.com/join/695548174
>
> Participants are advised to try the link before the call because it is
> going to download and install the software.
>
> Use your microphone and speakers (VoIP) - a headset is recommended. Or,
> call in using your telephone.
>
> Dial +1 (773) 897-3000
> Access Code: 695-548-174
> Audio PIN: Shown after joining the meeting
>
> Meeting ID: 695-548-174
>
> Nat or Mike will be the host for the call and they will start it.
>
> Ciao
> Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth