Subject: [OAUTH-WG] cert spoofing in mtls & short-lived certs

From: Leif Johansson <[email-masked]>
Date: Tue, 14 Nov 2017 09:44:01 +0100

So I reviewed the security considerations text which basically sais
that the server can avoid being spoofed by managing its set of trust
anchors. The text is better than nothing.

However this lead me to ask another question about the use of
SubjectDN as an identifier for the subject in client metadata: don't
we expect certificates to be issued as short-term credentials from
an STS-like thing?

If so the SubjectDN is probably going to change every time the STS
gets called (say by including a serial number) and such a SubjectDN
probably isn't the best thing to put in client metadata.

Would it make sense to make it possible to identify subjects based
on (say) SubjectAltName as an alternative for this case?

I don't want to hold up the process on this but I'm curious if this
has been raised or just overlooked...?

	Cheers Leif

---

From: Brian Campbell <[email-masked]>
Date: Tue, 14 Nov 2017 17:27:40 +0800

The expectation/assumption is that the SubjectDN would be a stable
identifier through re-issuance of certificates, regardless of whether they
be short or long term. We've had basically this as a product feature for
years and use of the SubjectDN as the identifier hasn't been an issue. And
it's not been raised, that I'm aware of anyway, as a concern in the banking
use-cases where there will be some central entity issuing these
certificates to the participants. Not sure if that exactly addresses your
question but that's how things got the way they are in the document.

If there's some better or additional text you'd like to see for the
security considerations, please do suggest it.

On Tue, Nov 14, 2017 at 4:44 PM, Leif Johansson <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*

---

From: Leif Johansson <[email-masked]>
Date: Tue, 14 Nov 2017 15:54:43 +0100

On 2017-11-14 10:27, Brian Campbell wrote:
> identifier through re-issuance of certificates, regardless of whether
> they be short or long term. We've had basically this as a product
> feature for years and use of the SubjectDN as the identifier hasn't been
> an issue. And it's not been raised, that I'm aware of anyway, as a
> concern in the banking use-cases where there will be some central entity
> issuing these certificates to the participants. Not sure if that exactly
> addresses your question but that's how things got the way they are in
> the document.

OK. That satisfies my curiosity.

> security considerations, please do suggest it.

In addition to what is there I might add something like this:

There is an assumption that the client and server agree on the set
of trust anchors the server uses to create and validate the
certificate chain. Without this assumption the use of a SubjectDN
to identify the client certificate would open the server up to
certificate spoofing attacks.

> 
> On Tue, Nov 14, 2017 at 4:44 PM, Leif Johansson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited.  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any
> file attachments from your computer. Thank you./
> 
>