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

[Leif Johansson <[e-mail]>]

On 2017-11-14 10:27, Brian Campbell wrote:
> 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.

OK. That satisfies my curiosity.

> 
> If there's some better or additional text you'd like to see for the
> 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 <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
> 
>     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
> 
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <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./
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>