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]>wrote:
> That would require special parsing. “alg”:”none” doesn’t.****
>
> ** **
>
> *From:* Richard Barnes [mailto:[email protected]]
> *Sent:* Thursday, August 01, 2013 5:03 AM
> *To:* Matt Miller (mamille2)
> *Cc:* jose issue tracker; <
> [email protected]>; Mike Jones; <
> [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]>
> 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] >
> Cisco Systems, Inc.****
>
>
> On Aug 1, 2013, at 1:23 PM, jose issue tracker <
> [email protected]> wrote:
>
> > #36: Algorithm "none" should be removed
> >
> >
> > Comment (by [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] | [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]
> > https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
