directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen, Sammi" <sammi.c...@intel.com>
Subject RE: Anonymous PKINIT signatures
Date Tue, 27 Sep 2016 07:08:18 GMT
Hi Colm,

I'm ramping up on this anonymous PKINIT signature issue. I may take a while to understand
the question and figure out the solution and would like to discuss with you when I have some
thoughts.

In the meantime, I'm trying to move on the Kerby 1.0.0-RC3 release. The community has implemented
new features, made a lot of improvements and bug fix since the RC2 release. With Hadoop 3.0
is about to release soon,  
It would be better if we can have a Kerby release in the near future. I'm afraid that it will
take me a longer time, and can't catch up the RC3 release. So I wonder if we can release RC3
first, and investigate and fix this issue at the same time. 
The solution can goes to next release. Your thoughts? 

Thanks,
Sammi
-----Original Message-----
From: Li, Jiajia [mailto:jiajia.li@intel.com] 
Sent: Thursday, July 28, 2016 9:46 AM
To: kerby@directory.apache.org; coheigea@apache.org
Subject: RE: Anonymous PKINIT signatures

Hi Colm,

When I looking at the krb5 source code, I found the function cms_signeddata_verify in pkinit_crypto_openssl.c
with the following comments:
" if (((si_sk = CMS_get0_SignerInfos(cms)) == NULL) ||
        ((si = sk_CMS_SignerInfo_value(si_sk, 0)) == NULL)) {
        /* Not actually signed; anonymous case */
        if (!is_signed)
            goto cleanup;
"
When the client parsing PA-PK-AS-REP message, it will call cms_signeddata_verify function.
So my point from here.
But what you said let me doubt myself, I will take some time to dig into this issue.

Thanks
Jiajia

-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Wednesday, July 27, 2016 8:59 PM
To: kerby@directory.apache.org
Subject: Re: Anonymous PKINIT signatures

Hi Jiajia,

It's the client that's anonymous here, and not the KDC. This page leads me to believe that
the KDC does in fact sign the response to the client:

http://web.mit.edu/kerberos/krb5-devel/doc/admin/pkinit.html

" For anonymous PKINIT, a KDC certificate is required, but client certificates are not.".
"The result of this operation will be in two files, kdckey.pem and kdc.pem.
Both files must be placed in the KDC’s filesystem. kdckey.pem, which contains the KDC’s
private key, must be carefully protected."

Colm.

On Tue, Jul 26, 2016 at 3:08 AM, Li, Jiajia <jiajia.li@intel.com> wrote:

> Hi Colm,
> >> However, the client doesn't use the certificate to verify a 
> >> signature,
> and thus proving that the KDC knows the private key associated with 
> the cert. Is this correct?
> You are right. I think anonymous case, not actually signed.
> Thanks,
> Jiajia
>
>
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Friday, July 22, 2016 11:22 PM
> To: Li, Jiajia <jiajia.li@intel.com>
> Cc: kerby@directory.apache.org
> Subject: Re: Anonymous PKINIT signatures
>
> Hi Jiajia,
> So if I understand you correctly, what you are saying is that it is 
> sufficient to verify that the Subject (alternative name) of the 
> Certificate matches that of the "known principal" of the KDC? In other 
> words, the KDC is not doing any asymmetric signature, it is just 
> "presenting" the certificate to the client. The client verifies that 
> the certificate is trusted, and then verifies that the KDC principal matches the certificate.
> However, the client doesn't use the certificate to verify a signature, 
> and thus proving that the KDC knows the private key associated with the cert.
> Is this correct?
> It's a bit unusual from a security POV but I think it's ok. We're 
> verifying trust in the certificate path and we're putting a hard 
> constraint on the Subject of the certificate. A malicious KDC/MITM 
> could forge a certificate, but then trust validation would fail, or 
> else get a certificate for another KDC, but then the constraint would 
> fail. So I think it's ok.
>
> Colm.
>
> On Fri, Jul 22, 2016 at 3:40 AM, Li, Jiajia <jiajia.li@intel.com<mailto:
> jiajia.li@intel.com>> wrote:
> Hi Colm,
> >> >However, I can't see where it is signing the response with the 
> >> >private
> key associated with the KDC. This is a requirement for anonymous 
> PKINIT
>
> Yes, you are right. The  "Identity" should be used in anonymous PKINIT.
> But now in client PkinitPreauth, start from line 393, we skip to use 
> the certificateSet which is returned by server, so now the code can't 
> verify the kdc sans, edu and so on. Such as the function 
> cryptoRetrieveX509Sans#PkinitCrypto is marked as TODO.
>
>
> Thanks
> Jiajia
>
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org<mailto:
> coheigea@apache.org>]
> Sent: Thursday, July 21, 2016 7:27 PM
> To: kerby@directory.apache.org<mailto:kerby@directory.apache.org>
> Subject: Anonymous PKINIT signatures
>
> Hi all,
>
> I'm continuing to look at anonymous PKINIT as implemented in Kerby. 
> I'm a bit puzzled by a few things relating to signatures and would 
> welcome some feedback.
>
> Looking at the server PkinitPreauth, it appears that Diffie-Hellman is 
> used to establish a shared secret key with the client. However, I 
> can't see where it is signing the response with the private key 
> associated with the KDC. This is a requirement for anonymous PKINIT, unless I am mistaken?
>
> Similarly, on the client side, it's not enough just to verify trust in 
> the Certificate that's presented, it also needs to be using the 
> Certificate to verify some signed data, to make sure that the KDC 
> knows the private key associated with the Certificate...
>
> I've updated the code so that the server at least includes the "Identity"
> Certificate in the response to the client.
>
> Thanks,
>
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Mime
View raw message