Subject: [OAUTH-WG] Few questions about HOTK

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 20 Dec 2012 21:49:15 +0000

Hi Hannes, others,

I'd like to understand what is the difference between HOTK Symmetric [1] 
and MAC [2].

I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK 
Symmetric text can support MAC.

My main question at the moment: does HOTK (Symmetric) offer an 
alternative to MAC or is HOTK actually a higher-level token scheme which 
can support different types of tokens ?

thanks, Sergey

[1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01
[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02

---

From: William Mills <[email-masked]>
Date: Thu, 20 Dec 2012 21:30:08 -0800 (PST)

MAC and HOTK describe different properties of a token, and could both be used in the same token.  MAC specifies a basic format for a signed token payload and transaction.  HOTK defines part of a token payload.  HOTK payload can be carried in a MAC token.

-bill

________________________________
 From: Sergey Beryozkin <[email-masked]>
To: "<[email-masked]>" <[email-masked]> 
Sent: Thursday, December 20, 2012 1:49 PM
Subject: [OAUTH-WG] Few questions about HOTK
 
Hi Hannes, others,

I'd like to understand what is the difference between HOTK Symmetric [1] and MAC [2].

I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK Symmetric text can support MAC.

My main question at the moment: does HOTK (Symmetric) offer an alternative to MAC or is HOTK actually a higher-level token scheme which can support different types of tokens ?

thanks, Sergey

[1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01
[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 21 Dec 2012 11:43:32 +0100

Hi Sergey,

in draft version -01 of draft-tschofenig-oauth-hotk we also included an example description of how to support symmetric keys since draft version -00 only provided support for asymmetric keys. There are essentially three ways for proof of possession of the keying material supported in that document, namely: (a) asymmetric keys, (b) JWS using symmetric keys, and (c) MAC tokens.

The symmetric key approach using JWS addresses a number of the requirements listed in draft-tschofenig-oauth-security-01, including

 - unique key naming (based on the JWS kid)
 - algorithm indication (based on features provided by JWS) but not negotiation
 - replay protection (based on features provided by JWS)
 - key scoping based on features inherited from JWT
 - resource owner identity confidentiality (based on JWT)
 - keyed message digest computation based on JWS (which is much easier for implementers than the canonicalization approach).

The question about key transport from the Authorization Server to the Resource Server (via JWE) is only raised and not solved. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Thu, 20 Dec 2012 21:49:15 +0000
> Von: Sergey Beryozkin <[email-masked]>
> An: "<[email-masked]>" <[email-masked]>
> Betreff: [OAUTH-WG] Few questions about HOTK

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 21 Dec 2012 11:15:39 +0000

On 21/12/12 05:30, William Mills wrote:
> MAC and HOTK describe different properties of a token, and could both be
> used in the same token. MAC specifies a basic format for a signed token
> payload and transaction. HOTK defines part of a token payload. HOTK
> payload can be carried in a MAC token.

Speaking of MAC, are you referring to
"mac" parameter within MAC Authorization payload representing a HOTK 
property ?

Cheers, Sergey

>
> -bill
>
> ------------------------------------------------------------------------
> *From:* Sergey Beryozkin <[email-masked]>
> *To:* "<[email-masked]>" <[email-masked]>
> *Sent:* Thursday, December 20, 2012 1:49 PM
> *Subject:* [OAUTH-WG] Few questions about HOTK
>
> Hi Hannes, others,
>
> [email-masked] <mailto:[email-masked]>

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 21 Dec 2012 11:29:55 +0000

Hi Hannes
> The question about key transport from the Authorization Server to the Resource Server (via JWE) is only raised and not solved.

I think I'm getting your earlier point now that HOTK and MAC are not 
equal in what they can offer, the concepts are somewhat orthogonal.

As far as MAC & HOTK are concerned, would be right to say that MAC offers:
- unique key naming (based on the MAC key id returned to the client)
- some support around replay protection based on Authorization MAC nonce 
& timestamp attributes
- key scoping ? (MAC attributes are bound to an access token which will 
expire)
- algorithm indication (ex, hmac-sha-1)

Note I'm not trying to prove MAC may be at the same level as JWS with 
respect to a number of HOTK properties that can be supported or the 
security requirements that can be met, rather I'd like to grasp what 
exactly MAC offers with respect to the HOTK discussion :-)

Cheers, Sergey

>> Von: Sergey Beryozkin<[email-masked]>
>> An: "<[email-masked]>"<[email-masked]>

---

From: William Mills <[email-masked]>
Date: Fri, 21 Dec 2012 07:52:02 -0800 (PST)

I want to argue to change that.  I think they should be separate and that the full token type definitiuon should be removed, defining only the key assertion.  ANY token that needs signing by the client could be an HOK token.

________________________________
 From: "[email-masked]" <[email-masked]>
To: William Mills <[email-masked]> 
Cc: "<[email-masked]>" <oauth,[email-masked]>; SergeyBeryozkin <[email-masked]> 
Sent: Thursday, December 20, 2012 11:46 PM
Subject: Re: Re: [OAUTH-WG] Few questions about HOTK

[email-masked] 写于 2012-12-21 13:30:08:

> MAC and HOTK describe different properties of a token, and could 
> both be used in the same token.  MAC specifies a basic format
for a 
> signed token payload and transaction.  HOTK defines part of a
token 
> payload.  HOTK payload can be carried in a MAC token. 
> 
> -bill 

HOTK and MAC are different token types, how can they
be used in the same token? 
What whould the token type be then?  

MAC and HOTK-SK are really very similar, they are
actually alternative solutions to each other.  
The meaning is HOTK is more high level.  
> alternative to MAC or is HOTK actually a higher-level token scheme 
> which can support different types of tokens ?
> 
> thanks, Sergey
>

---

From: William Mills <[email-masked]>
Date: Fri, 21 Dec 2012 07:54:54 -0800 (PST)

No, MAC as I'm using it is a MAC token per http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02

________________________________
 From: Sergey Beryozkin <[email-masked]>
To: William Mills <[email-masked]> 
Cc: "<[email-masked]>" <[email-masked]> 
Sent: Friday, December 21, 2012 3:15 AM
Subject: Re: [OAUTH-WG] Few questions about HOTK

Cheers, Sergey

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 21 Dec 2012 15:59:59 +0000

On 21/12/12 15:54, William Mills wrote:
> No, MAC as I'm using it is a MAC token per
> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02

Sure, what do you mean though when saying
"HOTK payload can be carried in a MAC token." ?

I'm presuming you have in mind the parameters as defined in the draft, 
and specifically I thought it was the 'mac' attribute which is 
effectively a HOTK payload, possibly alongside few other Authorization 
MAC scheme attributes ?

Sergey

> *To:* William Mills <[email-masked]>
> *Cc:* "<[email-masked]>" <[email-masked]>
> *Sent:* Friday, December 21, 2012 3:15 AM
> *Subject:* Re: [OAUTH-WG] Few questions about HOTK
>
>  > *From:* Sergey Beryozkin <[email-masked]
> <mailto:[email-masked]>>
>  > *To:* "<[email-masked] <mailto:[email-masked]>>" <[email-masked]
> <mailto:[email-masked]>>
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>

---

From: William Mills <[email-masked]>
Date: Fri, 21 Dec 2012 08:32:56 -0800 (PST)

I would find using a "mac" attribute inside a MAC token confusing.  Inside a MAC token or any other client signed thing I'd probably call the keying assertion inside "key", and make the payload of that defined by token type since some things like EC have more than one value in the keying information.

Sent: Friday, December 21, 2012 7:59 AM

Sergey

>  > MAC and HOTK describe different properties of a token, and could both be
>  > used in the same token. MAC specifies a basic format for a signed token
>  > payload and transaction. HOTK defines part of a token payload. HOTK
>  > payload can be carried in a MAC token.
>
>  >
>  > -bill
>  >
>  > ------------------------------------------------------------------------
>  > *From:* Sergey Beryozkin <[email-masked]
>  > *To:* "<[email-masked] <mailto:[email-masked]>>" <[email-masked]
> <mailto:[email-masked]>>
>  > *Sent:* Thursday, December 20, 2012 1:49 PM
>  > *Subject:* [OAUTH-WG] Few questions about HOTK
>  >
>  > Hi Hannes, others,
>  >
>  > I'd like to understand what is the difference between HOTK Symmetric [1]
>  > and MAC [2].
>  >
>  > I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK
>  > Symmetric text can support MAC.
>  >
>  > My main question at the moment: does HOTK (Symmetric) offer an
>  > alternative to MAC or is HOTK actually a higher-level token scheme which
>  > can support different types of tokens ?
>  >
>  > thanks, Sergey
>  >
>  > [1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01
>  > [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
>  > _______________________________________________
>  > OAuth mailing list
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  > https://www.ietf.org/mailman/listinfo/oauth
>  >
>  >
>
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 21 Dec 2012 21:27:19 +0000

On 21/12/12 16:32, William Mills wrote:
> I would find using a "mac" attribute inside a MAC token confusing.
> Inside a MAC token or any other client signed thing I'd probably call
> the keying assertion inside "key", and make the payload of that defined
> by token type since some things like EC have more than one value in the
> keying information.

OK. Actually, the draft uses "mac_key" to identify the key inside the 
token on the outbound path from the server, and "access_token" assumes 
the role of key identifier which is quite minimalistic, the access token 
has gone - the key has gone, hence the key scoping is supported...

"mac" is use on the path from a client to the server - but it is not 
part of the token as far as I understand - it is the client 
demonstration of the fact it received MAC token with the "mac_key" 
inside it; naming "mac_key" as simply "key" (which I read you 
suggesting) is a good idea IMHO

Sergey

> *Sent:* Friday, December 21, 2012 7:59 AM
>  > *To:* William Mills <[email-masked]
> <mailto:[email-masked]>>
>  > *Cc:* "<[email-masked] <mailto:[email-masked]>>" <[email-masked]
> <mailto:[email-masked]>>
> both be
> <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>>
>  > > *To:* "<[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>" <[email-masked]
> <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>>