You already have to have code to verify that the "alg" value used is one that
your application accepts. You'll already reject it if it's not in your
supported algorithm set. If your application doesn't want to accept
"alg":"none" the same code path that would reject "alg":"rot13" would reject
"alg":"none".
I'm not making your code more complicated. I'm sure that you already have the
code to reject algorithms your application doesn't support.
-- Mike
From: Richard Barnes [mailto:[email protected]]
Sent: Thursday, August 01, 2013 5:20 AM
To: Mike Jones
Cc: Matt Miller (mamille2); jose issue tracker;
<[email protected]>; <[email protected]>
Subject: Re: [jose] #36: Algorithm "none" should be removed
Sure it requires special parsing. You have to have special checking when
there's "alg":"none" to make sure there's no "kid" or "x5c", or anything else
that would hint at a downgrade attack. It's far more complicated than:
switch (token.split(".").length) {
case 2: process_unsigned(token); break;
case 3: process_signed(token); break;
case 5: process_encrypted(token); break;
default: throw new MalformedTokenError();
}
Why are you always trying to make my code more complicated, Mike? :)
I have sent a mail to the OAuth list suggesting a revision to the JWT spec.
--Richard
On Thu, Aug 1, 2013 at 2:11 PM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
That would require special parsing. "alg":"none" doesn't.
From: Richard Barnes [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, August 01, 2013 5:03 AM
To: Matt Miller (mamille2)
Cc: jose issue tracker;
<[email protected]<mailto:[email protected]>>;
Mike Jones; <[email protected]<mailto:[email protected]>>
Subject: Re: [jose] #36: Algorithm "none" should be removed
If you really want to have a header, you could also have the unsigned JWT have
2 components (1 dot). That way, you would demux unsigned/signed/encrypted
based on number of dots, not "alg".
--Richard
On Thu, Aug 1, 2013 at 1:51 PM, Matt Miller (mamille2)
<[email protected]<mailto:[email protected]>> wrote:
If something doesn't have a signature (or MAC, yeah yeah yeah), then I have a
really hard time calling it a JWS (JSON Web Signature), and there fore have a
really hard time seeing "alg":"none" as useful.
Assuming this is using compact serialization: Why not just send in the
base64url(payload)? Then you can tell if you have an actually signed JWT (3
dots) versus an unsigned JWT (0 dots).
- m&m
Matt Miller < [email protected]<mailto:[email protected]> >
Cisco Systems, Inc.
On Aug 1, 2013, at 1:23 PM, jose issue tracker
<[email protected]<mailto:trac%[email protected]>> wrote:
> #36: Algorithm "none" should be removed
>
>
> Comment (by [email protected]<mailto:[email protected]>):
>
> And sure enough, working groups across the IETF are having to explicitly
> forbid the use of null ciphersuites. They provide empirical evidence that
> this design pattern is a bad idea.
>
> As I've pointed out before, you can add that verification algorithm, but
> you will not have a good time writing security considerations around it.
> Checking that you support "none" is not enough -- you have to check that
> *nothing* *else* in the header could possibly indicate that a different
> signature algorithm should be used.
>
> So we have something that (1) causes a lot of spec work, (2) causes
> security vulnerabilities under likely implementaiton designs, and (3) has
> no use case, and (4) will haunt us for years to come (how many times do
> you want to write 'MUST NOT use "alg":"none"'?). Sounds like a recipe for
> success!
>
> --
> -------------------------+-------------------------------------------------
> Reporter: | Owner: draft-ietf-jose-json-web-
> [email protected]<mailto:[email protected]> |
> [email protected]<mailto:[email protected]>
> Type: defect | Status: new
> Priority: major | Milestone:
> Component: json-web- | Version:
> signature | Resolution:
> Severity: - |
> Keywords: |
> -------------------------+-------------------------------------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/36#comment:4>
> jose <http://tools.ietf.org/jose/>
>
> _______________________________________________
> jose mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
