Re: TLS: assigning certificates to username
I'm sure it is already documented, how to assign certificates to a dedicated username. But I so far didn't find it.
To my knowledge a TLS certificate will contain a username (a NAI) in TLS-Client-Cert-Common-Name. You can always check that if the TLS name does not match the username specified, you reject the request? :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On 5 May 2016, at 05:46, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
I'm sure it is already documented, how to assign certificates to a dedicated username. But I so far didn't find it.
To my knowledge a TLS certificate will contain a username (a NAI) in TLS-Client-Cert-Common-Name.
It *may* contain a CN, and that *may* be an NAI. No guarantees :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On May 5, 2016, at 10:22 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
It *may* contain a CN, and that *may* be an NAI.
Most importantly, it's under the control of the admin who's issuing the certs. So... 99% of people use the NAI in the common name. Doing anything else is crazy. Alan DeKok.
On 5 May 2016, at 10:52, Alan DeKok <aland@deployingradius.com> wrote:
On May 5, 2016, at 10:22 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
It *may* contain a CN, and that *may* be an NAI.
Most importantly, it's under the control of the admin who's issuing the certs.
So... 99% of people use the NAI in the common name.
and i'm 100% sure you're completely wrong :)
Doing anything else is crazy.
That'd be why RFC 6818 gives an example of common name being the user's full name? Standard sets of attributes have been defined in the X.500 series of specifications [X.520]. Implementations of this specification MUST be prepared to receive the following standard attribute types in issuer and subject (Section 4.1.2.6) names: * country, * organization, * organizational unit, * distinguished name qualifier, * state or province name, * common name (e.g., "Susan Housley"), and * serial number. and RFC 5216 (EAP-TLS) states pretty plainly that: Where the peer identity represents a host, a subjectAltName of type dnsName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in Section 2.1 of [RFC4282]. If a dnsName or rfc822Name are not available, other field types (for example, a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used. So in fact I revise my previous statement, if your cert contains an NAI in the CN part of the subject, your system administrator is an idiot. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
So in fact I revise my previous statement, if your cert contains an NAI in the CN part of the subject, your system administrator is an idiot.
and if you check your Network RADIUS issued S/MIME certificate. Oh, oh what's that? A subjectAltName with your username as an NAI? Look at that :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
So in fact I revise my previous statement, if your cert contains an NAI in the CN part of the subject, your system administrator is an idiot.
and if you check your Network RADIUS issued S/MIME certificate. Oh, oh what's that? A subjectAltName with your username as an NAI? Look at that :)
Catfight! ;-) user@example.com.pem in the FreeRADIUS directory yields this: root@debian8:/etc/freeradius/certs# openssl x509 -in user\@example.com.pem -text Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha256WithRSAEncryption Issuer: C=FR, ST=Radius, L=Somewhere, O=Example Inc./emailAddress=admin@example.com, CN=Example Certificate Authority Validity Not Before: Apr 28 20:57:32 2016 GMT Not After : Jun 27 20:57:32 2016 GMT Subject: C=FR, ST=Radius, O=Example Inc., CN=user@example.com/emailAddress=user@example.com Subject Public Key Info: [trimmed] X509v3 extensions: [trimmed] Signature Algorithm: sha256WithRSAEncryption [trimmed] There the Subject CN contains... a NAI? ;-) Is that standards-compliant? Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On 5 May 2016, at 12:31, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
So in fact I revise my previous statement, if your cert contains an NAI in the CN part of the subject, your system administrator is an idiot.
and if you check your Network RADIUS issued S/MIME certificate. Oh, oh what's that? A subjectAltName with your username as an NAI? Look at that :)
Catfight! ;-)
user@example.com.pem in the FreeRADIUS directory yields this:
root@debian8:/etc/freeradius/certs# openssl x509 -in user\@example.com.pem -text Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: sha256WithRSAEncryption Issuer: C=FR, ST=Radius, L=Somewhere, O=Example Inc./emailAddress=admin@example.com, CN=Example Certificate Authority Validity Not Before: Apr 28 20:57:32 2016 GMT Not After : Jun 27 20:57:32 2016 GMT Subject: C=FR, ST=Radius, O=Example Inc., CN=user@example.com/emailAddress=user@example.com Subject Public Key Info: [trimmed] X509v3 extensions: [trimmed] Signature Algorithm: sha256WithRSAEncryption [trimmed]
There the Subject CN contains... a NAI? ;-)
Um, check again :P -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On May 5, 2016, at 11:06 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Where the peer identity represents a host, a subjectAltName of type dnsName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in Section 2.1 of [RFC4282]. If a dnsName or rfc822Name are not available, other field types (for example, a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used.
OK.. so another one of the million fields available in the cert. <sigh> Alan DeKok.
On Thu, May 05, 2016 at 11:24:08AM -0400, Alan DeKok wrote:
On May 5, 2016, at 11:06 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Where the peer identity represents a host, a subjectAltName of type dnsName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in Section 2.1 of [RFC4282]. If a dnsName or rfc822Name are not available, other field types (for example, a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used.
OK.. so another one of the million fields available in the cert. <sigh>
But the point being, the client certificates are generated locally. So if one puts something useless in the cert, "its yer own fault" :) Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi,
So in fact I revise my previous statement, if your cert contains an NAI in the CN part of the subject, your system administrator is an idiot.
but if we are being pragmatic.. subjectAltName used for proxying decisions in EAP-TLS? the commonname is used - therefore , unless ALL RADIUS servers are under your control/remit/purview you have to work with the lowest common denominator...and in eg global RADIUS federated systems such as eduroam - that means using CommonName for the NAI location. obviously, for internal systems, you could bury the userinfo ANYWHERE in the cert....even use a nice local private x509 extension.... alan
On 5 May 2016, at 15:11, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
So in fact I revise my previous statement, if your cert contains an NAI in the CN part of the subject, your system administrator is an idiot.
but if we are being pragmatic.. subjectAltName used for proxying decisions in EAP-TLS?
No.
the commonname is used
I'm not sure what your point is. Certificates aren't used in proxying decisions. They can't be. It's too late by the time you've received the certificate from the supplicant. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 5 May 2016, at 16:09, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 5 May 2016, at 15:11, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
So in fact I revise my previous statement, if your cert contains an NAI in the CN part of the subject, your system administrator is an idiot.
but if we are being pragmatic.. subjectAltName used for proxying decisions in EAP-TLS?
No.
the commonname is used
I'm not sure what your point is. Certificates aren't used in proxying decisions. They can't be. It's too late by the time you've received the certificate from the supplicant.
My main reason for being less than enthusiastic about using CN for NAIs, is because in LDAP (also X509) CN is usually the user's humanly readable name, so you're creating discordant representations of the user. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 5 May 2016, at 16:25, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 5 May 2016, at 16:09, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 5 May 2016, at 15:11, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
So in fact I revise my previous statement, if your cert contains an NAI in the CN part of the subject, your system administrator is an idiot.
but if we are being pragmatic.. subjectAltName used for proxying decisions in EAP-TLS?
No.
the commonname is used
I'm not sure what your point is. Certificates aren't used in proxying decisions. They can't be. It's too late by the time you've received the certificate from the supplicant.
My main reason for being less than enthusiastic about using CN for NAIs, is because in LDAP (also X509)
*X500. Maybe idiot was too harsh. Just saying it's probably not a good thing to do :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell wrote:
My main reason for being less than enthusiastic about using CN for NAIs, is because in LDAP (also X509) CN is usually the user's humanly readable name, so you're creating discordant representations of the user.
That doesn't matter today anymore. In a modern setup you would attach the whole subject DN to the user's LDAP entry or define another attribute mapping. Ciao, Michael.
Hi,
My main reason for being less than enthusiastic about using CN for NAIs, is because in LDAP (also X509) CN is usually the user's humanly readable name, so you're creating discordant representations of the user.
you have to fix all supplicants then - it seems that if you want to set things nicely, the supplicant will recognise that as the email address or subjectAltName RFC values etc - but it uses the CN for the outer ID by default (if its not set as something else already in the supplicant) - from brief/rapid testing of some common clients. alan
Dear list, [snip]
To my knowledge a TLS certificate will contain a username (a NAI) in TLS-Client-Cert-Common-Name.
You can always check that if the TLS name does not match the username specified, you reject the request?
[snip] many thanks for the comments. I activated `check_cert_cn' in eap.conf. Now users can't choose a login name by their own and so bypass user specific regulations. Jens
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
dump＠gmx.info -
Matthew Newton -
Michael Ströder -
Stefan Paetow