headers
Douglas E. Engert | 1 Jul 2004 16:48
Favicon

krb-wg Agenda for 60th IETF - draft 0.0

The next meeting is a month away. We need get the agenda mooving and decied
on how much time we need. this week. (I will be on vacation next week,
so I asking Jeff if he can drive this while I am gone.    

Here is the first cut. Suggestions?

Kerberos WG  (krb-wg) 

<Dayofweek>  August xx, 2004
nnnn-nnnn {Morning|Afternoon|Evening} Sessions NN
======================================================

AGENDA:

  Introduction  
        Doug Engert, Jeff Hutzelman - 5 min
        Agenda bashing, appointing a scribe

  WG Priorities - Doug and Jeff  - 10 Min
	set milestones for the WEB page There are way out of date. 
	We need to set a few important ones we can meet. 

  
  PKinit - Brian? Jeff?  - (As long as it takes) min
        OSCP  
        Other issues. 
	At the interim meeting it was promised to have the wire protocol fixed,
	but maybe not the text. We are way behind on this, and need to get it
        out.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nicolas Williams | 1 Jul 2004 18:25
Picon

Re: krb-wg Agenda for 60th IETF - draft 0.0

Change password protocol, v2.

I intend to get a new version out soon-ish -- before the cutoff,
definitely.

Nico
-- 

On Thu, Jul 01, 2004 at 09:48:45AM -0500, Douglas E. Engert wrote:
> The next meeting is a month away. We need get the agenda mooving and decied
> on how much time we need. this week. (I will be on vacation next week,
> so I asking Jeff if he can drive this while I am gone.    
> 
> Here is the first cut. Suggestions?
> 
> Kerberos WG  (krb-wg) 
> 
> <Dayofweek>  August xx, 2004
> nnnn-nnnn {Morning|Afternoon|Evening} Sessions NN
> ======================================================
> 
> 
> AGENDA:
> 
>   Introduction  
>         Doug Engert, Jeff Hutzelman - 5 min
>         Agenda bashing, appointing a scribe
> 
>   WG Priorities - Doug and Jeff  - 10 Min
> 	set milestones for the WEB page There are way out of date.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Rex | 1 Jul 2004 22:39
Picon
Favicon

Re: OCSP thoughts

Nicolas Williams wrote:
> 
> Adding PK into the mix changes the game.  Now we can have revocation of
> KDC's creds, so why not?

Yup, but it doesn't make things more secure that way (actually PK&Trust
makes it less secure).

With PKINIT it seems to have to trust (1) the KDC, (2) the KDCs CA and
the (3) OCSP server, whereas with traditional Kerberos it was only the KDC.

From an engineering standpoint, forcing each and every client to hassle with
certificate revocation appears like a serious architectural flaw,
especially in the face of all the clients problems to actually perform
OCSP that have been mentioned.
(That lots of PKI-based software is poorly architectures in just that
 way doesn't make it any better).

Ideally, the KDC should provide the proof (didn't I read that OCSP
responses can be cached somewhere?) that his cert is still valid
along with his cert, and any client that wants to perform the
revocation check can use it, all others ignore it.  That would
be by far the most efficient way to do it (saving a roundtrip on PKINIT)
and there would not be any more problem with the clients lack of
connectivity.

Now if some PKI freak comes along and tells me that his client
trusts the CA the KDCs cert, trusts the KDC in case the KDCs
cert can be verified but doesn't want to trust the particular OCSP
server which the KDC used, then I would definititely consider him nuts.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Jeffrey Altman | 1 Jul 2004 22:52
Favicon

Re: OCSP thoughts

Martin Rex wrote:

>If OCSP responses can really be cached, then it should be possible
>to skip the request and piggy-back the OCSP response on the message
>carrying the KDC cert.  In a way, this would entirely remove OCSP tunneling.
>
>  
>
I do not believe that OSCP responses can be cached. 

There is a possibility that the KDC could be an authorized OCSP server 
in order to cut down
on the round trips from the KDC to the CA.  However, this model is not 
in line with the majority
of the CA business models.   

>-Martin
>
>  
>
Permalink | Reply | 1 comment |
headers
Nicolas Williams | 1 Jul 2004 22:59
Picon

Re: OCSP thoughts

On Thu, Jul 01, 2004 at 10:39:33PM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > Adding PK into the mix changes the game.  Now we can have revocation of
> > KDC's creds, so why not?
> 
> Yup, but it doesn't make things more secure that way (actually PK&Trust
> makes it less secure).
> 
> With PKINIT it seems to have to trust (1) the KDC, (2) the KDCs CA and
> the (3) OCSP server, whereas with traditional Kerberos it was only the KDC.

In traditional Kerberos authentication of the KDC and the client
principals is symmetric -- the same item (long-term keys) is used to
authenticate both.

With PKINIT we get to do better, so why not?  What's wrong with doing
better?

> 
> From an engineering standpoint, forcing each and every client to hassle with
> certificate revocation appears like a serious architectural flaw,
> especially in the face of all the clients problems to actually perform
> OCSP that have been mentioned.
> (That lots of PKI-based software is poorly architectures in just that
>  way doesn't make it any better).

I don't want to argue about whether or not PKI is a hassle.  Cert
revocations is part and parcel of PKI and can only be truly avoided by
using short-lived certs or by ignoring the problem altogether.  PKINIT
(Continue reading)

Permalink | Reply | 8 comments |
headers
Nicolas Williams | 1 Jul 2004 23:08
Picon

Re: OCSP thoughts

On Thu, Jul 01, 2004 at 02:07:21PM -0700, Liqiang(Larry) Zhu wrote:
> Martin Rex wrote:
> Nicolas Williams wrote:
> > > Martin Rex wrote:
> > > To me, being able to tell KDC-certs from non-KDC certs appears more 
> > > significant than to get OCSP reassurance.
> > 
> > Really?
> 
> Please convince me why an MITM attack is not possible if the client can
> not tell if the KDC cert is really from a KDC.

Larry, see my reply to Martin's reply to that.  I was not arguing that
we shouldn't have a way to distinguish KDC vs. non-KDC certs!  Just that
that doesn't make the need for KDC cert revocation checking go away.

Note to self: don't be too terse! :) :)

Nico
--

--
Permalink | Reply | 0 comments |
headers
Liqiang(Larry) Zhu | 1 Jul 2004 23:07
Picon
Favicon

RE: OCSP thoughts

Martin Rex wrote:
> How?

> If OCSP responses can really be cached, then it should be possible to
skip the request and piggy-back the OCSP response > 
> on the message carrying the KDC cert.  In a way, this would entirely
remove OCSP tunneling.

Please take a look at ID smime-rfc3369bis and also my earlier email
response to Nico.

> The only certificate(s) for which a KDC should process a tunneled OCSP
request is the KDCs own certificate(s), everything > else opens
additional DoS attack surface (resource exhaustion), so *personally* I
think full OCSP tunneling is overkill 
> here (besides requiring an additional roundtrip).

This is exactly right. Why the clients need OCSP response for any cert
other than that of the KDC?

Nicolas Williams wrote:
> > Martin Rex wrote:
> > To me, being able to tell KDC-certs from non-KDC certs appears more 
> > significant than to get OCSP reassurance.
> 
> Really?

Please convince me why an MITM attack is not possible if the client can
not tell if the KDC cert is really from a KDC.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Balluffi | 1 Jul 2004 23:39

Re: OCSP thoughts

Jeffrey Altman said:

"I do not believe that OSCP responses can be cached."

Tumbleweed (formerly Valicert) and CoreStreet cache OCSP responses. See 
http://www.tumbleweed.com/products/validationauthority/evafeatures.html 
and http://www.corestreet.com/whitepapers/w03-07v1_nonce-sense.pdf.

Frank
Permalink | Reply | 0 comments |
headers
Martin Rex | 1 Jul 2004 23:47
Picon
Favicon

Re: OCSP thoughts

Jeffrey Altman wrote:
> >
> I do not believe that OSCP responses can be cached. 

I just looked at rfc2560 (PKIX OCSP), and to me it looks like there's
no field in the response tying it to a particular request (which would
preclude caching).  But there is a validity information in the
OCSP reply, which would give an idea for how long the OCSP response
can be cached.

-Martin

Quoting rfc2560, page 3:

   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA

   A definitive response message is composed of:

   -- version of the response syntax
   -- name of the responder
   -- responses for each of the certificates in a request
   -- optional extensions
   -- signature algorithm OID
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Rex | 1 Jul 2004 23:59
Picon
Favicon

Re: OCSP thoughts

Nicolas Williams wrote:
> 
> > How often do you expect KDC certs to get revoked in the real world?
> 
> Every time a KDC implementation has a vulnerability discovered and
> patched.

Wow!  Actually, the pedantic would have to do it every time when
remotely-accessible software on the KDC machine has a vulnerability
discovered, not only the KDC code itself.

And if I'm not mistaken, then all the services still use traditional
shared-secret keys.  So if you assume compromise of the PKI credentials
of the KDC, you should equally assume compromise of all secret keys in
the KDC database and rekey them all, plus re-verify all the
X.509-cert <-> account mappings for PKINIT.

Now with all the Software that comes along on a Microsoft PDC,
this would be about once a week, wouldn't it?  So for large companies
that operate huge Microsoft domains the constant rekeying would provide
jobs for dozens of admins (plus a significant revenue stream for the CA...)

:)

-Martin
Permalink | Reply | 7 comments |

Gmane