Authentication

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Authentication

Mark-62
Hi All,

Thanks again to all here who helped me with my understanding of
Certificates.

It is likely that we would want to embed some additional data in
client certificates to further enhance security.  For example we
may wish to include a (list of) IP address(es) that the client
can connect from and reject those not on the list.  Alternatively
we could create a database of clients and their IP addresses on
the server and perform a lookup based on some unique identifier
in the client certificate.  I would be greatful for ideas on
the way to go here and how to implement it.

I am trying to allow for the case that the client may have their
private key lost or stolen.

TIA for any help...

Best Regards,
Mark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Bear Giles
Mark wrote:
> It is likely that we would want to embed some additional data in
> client certificates to further enhance security.  For example we
> may wish to include a (list of) IP address(es) that the client
> can connect from and reject those not on the list.  Alternatively
> we could create a database of clients and their IP addresses on
> the server and perform a lookup based on some unique identifier
> in the client certificate.  I would be greatful for ideas on
> the way to go here and how to implement it.

It seems like a Really Bad Idea to key to IP addresses in the
certificate.  They can not only change, they're often outside of
the client's control.  Fully qualified domain names are much
better.  Server certs use their FQDN as their Common Name.

On the server side, why not maintain a database of clients and
FQDNs or IP addresses?  What you gain in flexibility should more
than offset the increased complexity in the code.

Bear
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Bernhard Fröhlich-2
In reply to this post by Mark-62
Mark wrote:

>Hi All,
>
>Thanks again to all here who helped me with my understanding of
>Certificates.
>
>It is likely that we would want to embed some additional data in
>client certificates to further enhance security.  For example we
>may wish to include a (list of) IP address(es) that the client
>can connect from and reject those not on the list.  Alternatively
>we could create a database of clients and their IP addresses on
>the server and perform a lookup based on some unique identifier
>in the client certificate.  I would be greatful for ideas on
>the way to go here and how to implement it.
>
>I am trying to allow for the case that the client may have their
>private key lost or stolen.
>
>TIA for any help...
>
>Best Regards,
>Mark
>  
>
As I see it it's more or less a matter of taste wether you implement
such things using certificate extenstions or use the database approach.
Some things to consider:

- You can't modify certificate extensions, you'll have to create a new
certificate if the user gets a new IP-Adress
- Using certificate extensions may be preferable if you have many
servers and many (changing) users since then you won't have to
distribute the database to the servers
- Certificate extensions may cause compatibility problems if the
certificate is also to be used for other applications (like S/MIME)
- With the database approach it is much easier to "outsource" the
certificate creation (and renewal) process to some trusted third party CA.

IMHO certificates are for authentication and not for defining access
rights. The certificate says that I am "Bernhard Fröhlich" and if you
trust my CA you can trust in that. The database defines that "Bernhard
Fröhlich" has access to this and that thing, so it maps a CN to access
rights.

Lost or stolen certs should be handled by certificate revocation, at
least that's why certificate revocation and revocation checking was
implemented.
But as I said, there may be people with other opinions. Or situations
where immaculate theory is not the decisive factor. ;)

Hope it helps.
Ted
;)

--
PGP Public Key Information
Download complete Key from http://www.convey.de/ted/tedkey_convey.asc
Key fingerprint = 31B0 E029 BCF9 6605 DAC1  B2E1 0CC8 70F4 7AFB 8D26



smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Authentication

Mark-62
In reply to this post by Mark-62
Hi,

Thank you Bear and Ted for your responses.

> On the server side, why not maintain a database of clients and
> FQDNs or IP addresses?  What you gain in flexibility should more
> than offset the increased complexity in the code.

This is one of the options I am considering and, indeed, it does
seem the most suitable for our application.

What feature of a certificate could I use to provide an unique key
in a database table for this?  How could this be extracted in a
program?

Cheers, Mark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Bear Giles
Mark wrote:
> What feature of a certificate could I use to provide an unique key
> in a database table for this?  How could this be extracted in a
> program?

The Common Name.  You could use it as an LDAP key, convert it to a
string and use that a key into a database, etc.

One important nit -- you want to verify the issuer and should
actually check (issuer, common name) instead of just your common
name.  It reduces to the CN alone if you only accept your own
certificates.

If you don't check the issuer you're vulnerable to black hats
generating their own certificates and using them to gain access.

BTW, Ted was referring to the separation between "authentication"
(who are you) and "authorization" (what can you do).  It's a
standard security practice and you should think very hard before
combining the functions.  Checking IP address would be part of the
authentication step.

Bear
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Authentication

Mark-62
In reply to this post by Mark-62
Hi Bear,

> Mark wrote:
> > What feature of a certificate could I use to provide an unique key
> > in a database table for this?  How could this be extracted in a
> > program?
>
> The Common Name.  You could use it as an LDAP key, convert it to a
> string and use that a key into a database, etc.

How can this be done?  I can find virtually no documentation on the
relevant X509 functions.  I know I can get a pointer to an X509
object using SSL_get_peer_certificate(...) but I don't know how
to read certificate parameters from this.

> One important nit -- you want to verify the issuer and should
> actually check (issuer, common name) instead of just your common
> name.  It reduces to the CN alone if you only accept your own
> certificates.
>
> If you don't check the issuer you're vulnerable to black hats
> generating their own certificates and using them to gain access.

I'm not sure I understand this.  We are acting as the CA so noone else
should be able to sign certificates?

Cheers,
   Mark.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Victor Duchovni
On Wed, Nov 30, 2005 at 04:28:04PM -0000, Mark wrote:

> Hi Bear,
>
> > Mark wrote:
> > > What feature of a certificate could I use to provide an unique key
> > > in a database table for this?  How could this be extracted in a
> > > program?
> >
> > The Common Name.  You could use it as an LDAP key, convert it to a
> > string and use that a key into a database, etc.
>
> How can this be done?  I can find virtually no documentation on the
> relevant X509 functions.  I know I can get a pointer to an X509
> object using SSL_get_peer_certificate(...) but I don't know how
> to read certificate parameters from this.
>

From the Postfix 2.3-20051128 snapshot (the 2.3 code is simplified
relative to 2.2 and earlier):

src/tls/tls_verify.c:

#ifndef DONT_GRIPE
#define DONT_GRIPE 0
#define DO_GRIPE 1
#endif

/* tls_text_name - extract certificate property value by name */

static char *tls_text_name(X509_NAME *name, int nid, char *label, int gripe)
{
    int     len;
    char   *text;

    if ((len = X509_NAME_get_text_by_NID(name, nid, 0, 0)) < 0) {
        if (gripe != DONT_GRIPE) {
            msg_warn("peer certificate has no %s", label);
            tls_print_errors();
        }
        return (0);
    }

    /*
     * Since the peer CN is used in peer verification, take care to detect
     * truncation due to excessive length or internal NULs.
     */
    if (len >= CCERT_BUFSIZ) {
        msg_warn("peer %s too long: %d", label, (int) len);
        return (0);
    }
    text = mymalloc(len + 1);
    X509_NAME_get_text_by_NID(name, nid, text, len + 1);
    if (strlen(text) != len) {
        msg_warn("internal NUL in peer %s", label);
        myfree(text);
        text = 0;
    }
    return (text);
}

/* tls_peer_CN - extract peer common name from certificate */

char   *tls_peer_CN(X509 *peercert)
{
    char   *cn;

    cn = tls_text_name(X509_get_subject_name(peercert),
                       NID_commonName, "CN", DO_GRIPE);
    return (cn);
}

/* tls_issuer_CN - extract issuer common name from certificate */

char   *tls_issuer_CN(X509 *peer)
{
    X509_NAME *name;
    char   *cn;

    name = X509_get_issuer_name(peer);

    /*
     * If no issuer CN field, use Organization instead. CA certs without a CN
     * are common, so we only complain if the organization is also missing.
     */
    if (!(cn = tls_text_name(name, NID_commonName, "issuer CN", DONT_GRIPE)))
        cn = tls_text_name(name, NID_organizationName,
                           "issuer Organization", DO_GRIPE);
    return (cn);
}

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Peter Sylvester-3
In reply to this post by Bear Giles
Bear Giles wrote:

> Mark wrote:
>  
>> What feature of a certificate could I use to provide an unique key
>> in a database table for this?  How could this be extracted in a
>> program?
>>    
>
> The Common Name.  You could use it as an LDAP key, convert it to a
> string and use that a key into a database, etc.
>
>  
You probably mean the Subject DN.

--
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorite';
die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch.


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Peter Sylvester-3
In reply to this post by Victor Duchovni
The code below gives the FIRST Common Name RDN, not the last one in the
hierarchy
to be tested as a servername in tls. But well, if you only have one
occurrence of common name :-)

Anyway, the WHOLE DN, i.e. all attributes together are supposed to be
unique in a CA.
Of course, if your private CA makes the common name attribute unique ..
There may be more than one "Joe Smith"

There are utility function to get a string representation of the whole
subject, with many options about
the formatting, one almlowing to be used diurectly in a ldap request
etc. ==> cf apps/x509.c


Victor Duchovni wrote:

> On Wed, Nov 30, 2005 at 04:28:04PM -0000, Mark wrote:
>
>  
>> Hi Bear,
>>
>>    
>>> Mark wrote:
>>>      
>>>> What feature of a certificate could I use to provide an unique key
>>>> in a database table for this?  How could this be extracted in a
>>>> program?
>>>>        
>>> The Common Name.  You could use it as an LDAP key, convert it to a
>>> string and use that a key into a database, etc.
>>>      
>> How can this be done?  I can find virtually no documentation on the
>> relevant X509 functions.  I know I can get a pointer to an X509
>> object using SSL_get_peer_certificate(...) but I don't know how
>> to read certificate parameters from this.
>>
>>    
>
> >From the Postfix 2.3-20051128 snapshot (the 2.3 code is simplified
> relative to 2.2 and earlier):
>
> src/tls/tls_verify.c:
>
> #ifndef DONT_GRIPE
> #define DONT_GRIPE 0
> #define DO_GRIPE 1
> #endif
>
> /* tls_text_name - extract certificate property value by name */
>
> static char *tls_text_name(X509_NAME *name, int nid, char *label, int gripe)
> {
>     int     len;
>     char   *text;
>
>     if ((len = X509_NAME_get_text_by_NID(name, nid, 0, 0)) < 0) {
>         if (gripe != DONT_GRIPE) {
>             msg_warn("peer certificate has no %s", label);
>             tls_print_errors();
>         }
>         return (0);
>     }
>
>     /*
>      * Since the peer CN is used in peer verification, take care to detect
>      * truncation due to excessive length or internal NULs.
>      */
>     if (len >= CCERT_BUFSIZ) {
>         msg_warn("peer %s too long: %d", label, (int) len);
>         return (0);
>     }
>     text = mymalloc(len + 1);
>     X509_NAME_get_text_by_NID(name, nid, text, len + 1);
>     if (strlen(text) != len) {
>         msg_warn("internal NUL in peer %s", label);
>         myfree(text);
>         text = 0;
>     }
>     return (text);
> }
>
> /* tls_peer_CN - extract peer common name from certificate */
>
> char   *tls_peer_CN(X509 *peercert)
> {
>     char   *cn;
>
>     cn = tls_text_name(X509_get_subject_name(peercert),
>                        NID_commonName, "CN", DO_GRIPE);
>     return (cn);
> }
>
> /* tls_issuer_CN - extract issuer common name from certificate */
>
> char   *tls_issuer_CN(X509 *peer)
> {
>     X509_NAME *name;
>     char   *cn;
>
>     name = X509_get_issuer_name(peer);
>
>     /*
>      * If no issuer CN field, use Organization instead. CA certs without a CN
>      * are common, so we only complain if the organization is also missing.
>      */
>     if (!(cn = tls_text_name(name, NID_commonName, "issuer CN", DONT_GRIPE)))
>         cn = tls_text_name(name, NID_organizationName,
>                            "issuer Organization", DO_GRIPE);
>     return (cn);
> }
>
>  

--
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorite';
die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch.


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Bear Giles
In reply to this post by Peter Sylvester-3
Peter Sylvester wrote:
> Bear Giles wrote:
>> The Common Name.  You could use it as an LDAP key, convert it to a
>> string and use that a key into a database, etc.
>>
> You probably mean the Subject DN.

Yes.  oops.  I need to get better at proofreading. :)
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Victor Duchovni
In reply to this post by Peter Sylvester-3
On Wed, Nov 30, 2005 at 06:40:38PM +0100, Peter Sylvester wrote:

> The code below gives the FIRST Common Name RDN, not the last one in the
> hierarchy to be tested as a servername in tls.

Yes, that is its purpose, verifying DNS names in server certificates.
There is more code (not shown) that first looks at SubjectAltName:DNS...

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Peter Sylvester-3

C=FR;O=JANUS;CN="server1";CN=server2"

What I mean with LAST is: The code gives server1, but what should be
compared should be server2



Victor Duchovni wrote:

> On Wed, Nov 30, 2005 at 06:40:38PM +0100, Peter Sylvester wrote:
>
>  
>> The code below gives the FIRST Common Name RDN, not the last one in the
>> hierarchy to be tested as a servername in tls.
>>    
>
> Yes, that is its purpose, verifying DNS names in server certificates.
> There is more code (not shown) that first looks at SubjectAltName:DNS...
>  
Yes, I suppose, all kinds of ssl client apss have almost the same code,
and often make the same error. :-)
In fact, I believe that such code should be part of a utility function
in openssl
that gets the dnsname and/Ip address as input and says whether the cert
is good for that.


--
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorite';
die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch.


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Victor Duchovni
On Wed, Nov 30, 2005 at 07:32:07PM +0100, Peter Sylvester wrote:

>
> C=FR;O=JANUS;CN="server1";CN=server2"
>
> What I mean with LAST is: The code gives server1, but what should be
> compared should be server2
>

AFAIK multiple CNs are not valid in the context of at least server
certificates.  That is what SubjectAltName is for. The code in
question is cloned from original code by Lutz, which obtains
the CN in the same way.

> >Yes, that is its purpose, verifying DNS names in server certificates.
> >There is more code (not shown) that first looks at SubjectAltName:DNS...
>
> Yes, I suppose, all kinds of ssl client apss have almost the same code,
> and often make the same error. :-)

The original code was written by Lutz Jaenicke, was it wrong?

       if (dNSName_found) {
           if (!hostname_matched)
               msg_info("Peer verification: %d dNSNames in certificate found, but no one does match %s", dNSName_found, TLScontext->peername_save);
       } else {
           buf[0] = '\0';
           if (!X509_NAME_get_text_by_NID(X509_get_subject_name(err_cert),
                          NID_commonName, buf, 256)) {
               msg_info("Could not parse server's subject CN");
               pfixtls_print_errors();
           }
           else {
               hostname_matched = match_hostname(buf, TLScontext);
               if (!hostname_matched)
                   msg_info("Peer verification: CommonName in certificate does not match: %s != %s", buf, TLScontext->peername_save);
           }
       }

Under what conditions would I find two CNs in an SSL server certificate?

> In fact, I believe that such code should be part of a utility function
> in openssl
> that gets the dnsname and/Ip address as input and says whether the cert
> is good for that.
>

Well Postfix wants more control over the verification process, because
it optionally (and by default) allows unverified sessions to proceed, and
it wants to carefully support "*.domain.com" CNs with "*" matching just
one level of sub-domains, and ...

Ultimately, real-world applications write their own verification callbacks.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Authentication

Mark-62
In reply to this post by Mark-62
Hi All,

> The code below gives the FIRST Common Name RDN, not the last
> one in the hierarchy
> to be tested as a servername in tls. But well, if you only have one
> occurrence of common name :-)
>
> Anyway, the WHOLE DN, i.e. all attributes together are supposed to be
> unique in a CA.
> Of course, if your private CA makes the common name attribute
> unique .. There may be more than one "Joe Smith"
>
> There are utility function to get a string representation of
> the whole
> subject, with many options about
> the formatting, one almlowing to be used diurectly in a ldap request
> etc. ==> cf apps/x509.c

I must admit to being even more confused after the all the replies
to this thread!  Thanks for all the input ;-)

I have experimented with the code examples given and some do not
yield objects that look particularly unique (i.e. short strings).

The following code seems promising:

    cert = SSL_get_peer_certificate(ssl);
    subj = X509_get_subject_name(cert);
    if (X509_NAME_oneline(subj, data, 256))
    {
        printf("Peer subject='%s'", data);
    }

Can anyone comment whether this (data) would suffice? I also noted
that a hash value of this subject line is also available.  That
might yield a good database key?

Cheers,
   Mark.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Peter Sylvester-3

>> etc. ==> cf apps/x509.c
>>    
>
> I must admit to being even more confused after the all the replies
> to this thread!  Thanks for all the input ;-)
>
> I
Read apps/x509.c how it parses the different ways to format a subject
and issuer.

--
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Authentication

Mark-62
In reply to this post by Mark-62
Hi Peter,

> Read apps/x509.c how it parses the different ways to format a subject
> and issuer.

I've looked at that file but my understanding is still limited. There's
virtually no comments so it's hard to untangle what it is doing.

I noticed a function X509_subject_name_hash().  Will that give a unique
reference to a certificate?  It seems to ;-)

Cheers, Mark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Peter Sylvester-3

> I've looked at that file but my understanding is still limited. There's
> virtually no comments so it's hard to untangle what it is doing.
>
> I noticed a function X509_subject_name_hash().  Will that give a unique
> reference to a certificate?  It seems to ;-)
>  


There are several calls to a function print_name which you will find in
apps/apps.c
> Cheers, Mark
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>
>
>  


--
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Bear Giles
In reply to this post by Mark-62
Mark wrote:
> I noticed a function X509_subject_name_hash().  Will that give a unique
> reference to a certificate?  It seems to ;-)

No hash can be guaranteed to be unique.  Issuer and serial number
should be, but of course you need to exercise some intelligence here.

You can use the subject hash (or a subset) to perform quick
lookups.  E.g., if you have a large number of certs indexed by
their SN hash, you can quickly determine that you don't have the
specified cert or find a few possible matches.

In practice?  A 20-byte hash will almost certainly be unique.
What's your risk tolerance?

Bear
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Authentication

Mark-62
In reply to this post by Mark-62
Hi Bear,

> > I noticed a function X509_subject_name_hash().  Will that
> give a unique
> > reference to a certificate?  It seems to ;-)
>
> No hash can be guaranteed to be unique.  Issuer and serial number
> should be, but of course you need to exercise some intelligence here.
>
> You can use the subject hash (or a subset) to perform quick
> lookups.  E.g., if you have a large number of certs indexed by
> their SN hash, you can quickly determine that you don't have the
> specified cert or find a few possible matches.

In that case I'll use the Issuer and Serial number.  Thanks.

Cheers, Mark
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication

Bear Giles
Mark wrote:
>>No hash can be guaranteed to be unique.  Issuer and serial number
>>should be, but of course you need to exercise some intelligence here.
>
> In that case I'll use the Issuer and Serial number.  Thanks.

As I said, just remember to use some intelligence.  Verify the
issuer, be prepared for the case where a clueless CA issues the
same serial number (which is definitely an error, but how will you
handle it?), etc.

Bear
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
12