Hi Hannes
On 27/02/13 08:46, Hannes Tschofenig wrote:
Hi Sergey,
thanks for your input.
On Feb 26, 2013, at 2:36 PM, Sergey Beryozkin wrote:
Hi Hannes
On 25/02/13 12:46, Hannes Tschofenig wrote:
Hi all,
I just submitted an updated version of the draft-ietf-oauth-v2-http-mac-03.txt.
It definitely has more interesting content (about architecture, session keys,
etc) - this is really useful IMHO.
What I'm not really understanding is why a 2-way TLS transport for the session
key is not even considered.
Could you explain how this would look like?
Given my earlier confusion, and knowing it is a path between AS and RS,
what would prevent RS and AS exchanging their certificates and admins
configuring both to require a client certificate authentication ?
and then basically use some simple name/value exchange ? I don't mind
against having a JWT profile supported at the AS-to-RS path
What I find a bit unusual is the fact that this AS to RS path is even
covered - this is probably the first attempt AFAIK :-), though I guess
it must be important to do it
Instead this uber-complex (in the context of this spec, IMHO) JWT thing is
there once again. I appreciate why it may be the case, primarily to do with
reusing the work done around JWT and having some common/recommended access
token representation, but disallowing a basic bearer token be 'enhanced' with
MAC over two-way TLS seems like not ideal at all IMHO.
Note that JWT is used only for the access token encoding.
To be honest, I'm not sure why would anyone use JWT+MAC instead of just JWE,
Actually, the authorization server encrypts the access token using JWE and the
client uses MAC.
So, using JWT + MAC is actually not possible since the security mechanisms are
used by different entities: the MAC is used by the client and the access token
protection is accomplished by the authorization server.
Sorry, I got confused earlier :-)
thanks, Sergey
in cases when people are really comfortable with doing JWT. I guess we may be
talking now about better security characteristics, but this will help a very
limited audience as compared to a wider one which can use Bearer+MAC over 2-way
TLS, straightforward, very cheap effort to get started.
Ciao
Hannes
just my 2c
Thanks, Sergey
I would like to point out that this is **discussion input** -- not agreed
content. Anything in the document is subject to change!
You also may notice that there are a few questions in the writeup.
I was trying to more specific about some of the design aspects that folks had
proposed during the last few months.
I have also re-submitted the draft-tschofenig-oauth-hotk, which includes a TLS
and a JSON-based solution approach.
In general, the open questions still seem to be related to
* Key distribution: What should be described in a document? What is mandatory
to implement?
* Selective header field protection: This is something that was brought forward
in discussions and I have included a proposal of how this could look like.
* Channel Binding: Functionality is also included to deal with
man-in-the-middle attacks against TLS. There are, however, two types of channel
bindings defined in RFC 5929. Are both needed? If not, which one should be
selected?
* Integrity protection and data origin authentication in both directions: The
current writeup allows the protection to be extended to messages beyond the
initial request. This also offers key confirmation by the server and protection
of any responses.
Writing the text I also noticed that I do not quite understand how nested JWT
documents are supposed to look like. For example, how do I encrypt the mac_key
carried inside the JWT plus add a signature of all other fields? Currently, I
have just encrypted the entire payload.
I hope to have some discussions prior to the IETF meeting so that we have a
more fruitful discussion at the face-to-face meeting.
Ciao
Hannes
_______________________________________________
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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
