John's Security Section Review Result

[Nat Sakimura]

5.2.1 - bullet 2.

12 characters --- entropy language needed. Ref. Connect at least 128bits Perhaps use OIDC 16.19. Symmetric Key Entropy

add for the confidential clients RSA: 2K ~ 120bits Sym: 128 bits 32 octs Eliptic Curve: min key length of 160 bits

5.2.1 - 3rd last bullet

Constrain the length of the validity of code. 15 seconds after the redirect was initiated to the client.

Put it in the last NOTE as well.

5.2.2 Public Client

Change the first two bullets to:

• shall support RFC7636 or the mechanisms defined in Part 4.
• shall use S256 as the code challenge method for the RFC7636;

Replace BCP NAPPS with OAuth 2.0 for Native Apps [O2fNA]

6.2.1 Protected resources provisions

s/shall mandate TLS 1.2 as defined in RFC5246 or later /shall mandate TLS 1.2or later as defined in RFC5246/

add

if it decides to provide access to javascript clients.

NOTE: Providing access to Javascript clients and not has different security properites.

to

Further, itshould support the use of Cross Origin Resource Sharing (CORS) [CORS] and or other methods as appropriate to enable Java Script Clients to access the endpoint;

6.2.2 Client provisions

• First bullet -- same as in 6.2.1.

• Minimum entropy of opaque access token. 128 bits

  • check security considerations as well.
  • security these API with small entropy access tokens would ...
  • non monotonically increasing or .. guessable.
  • cf. 5.1.4.2.2 of RFC6819

• Put NOTE: User-Agent and DDA-FinancialId is not a security feature.

Client Authentication of confidential clients

Mandate either:

1. TLS Mutual Auth to the token endpoint
2. JWS Assertion Client Auth to the token endpoint (cf. OIDC.)

[Sascha Preibisch]

Comment on 5.2.1 - 3rd last bullet:

I think 15s is pretty short. Especially in the context of mobile apps. They may lose the connection and the code has expired once the connection is back.

I suggest a 1 minute lifetime for the code. That should not be a security issue especially because it is usable only once. And it will the usability.

[Nat Sakimura]

Sascha, the point here is to make it either

1. one time use only; or
2. does not enforce the one time only but has a short validity period.

You wrote that 1 min. is fine since the code is one time use only, but if it is not, what would you suggest?

[John Bradley]

5.2.1 the lifetime of code can be longer if you are using PKCE S256 as the code cannot be used if stolen so the lifetime is more about cache control at that point.

[Sascha Preibisch]

Yes, I agree. The lifetime is like a cache control. But the cache lifetime should not be too short to have users not go through the authorization process again only because the code has been removed from the cache after being offline for a short time.

@Nat : If we do not have a limited lifetime servers have to remember a code forever in the case where a client requests codes but never uses them. One-time use for me is a must.

I know that in general the code will be issued and used within seconds. But I am a server guy and I am always assuming that, let's say, badly implemented clients, try to use my services

[Nat Sakimura]

@ve7jtb , the draft mandates PKCE with S256. Does that mean we do not need to time bind the code? I still think that setting an expectation to the client that code cannot be used for example after 60 seconds. That allows the server to delete the code then.

[Nat Sakimura]

Just put NOTE noting the cache clearance.

[Edmund Jay]

fixes #33 - John's Security Section Review Result

→ <<cset 8d2390c7fab7>>