I still fail to see how you are improving on the paper written by Russ
Housely who I think knows rather more about this area than you have
demonstrated so far.
I am quite familiar with the security considerations section of the OCSP
specification, I wrote the original.
I cited OCSP as a proof that the operational requirements are manageable.
OCSP was designed to support certain operational criteria. If it is
desirable to imrove on those criteria it is possible to supplement the
digital signature with an HMAC construction. While this is not currently a
specified operating mode for OCSP the capability could be added without
difficulty and is in fact already defined for XKMS operating over SOAP using
the Web Services Security mechanism with a key exchange such as
WS-SecureConversation.
XMKS is not currently deployed over the ATLAS infrastructure but there is no
reason why this could not be achieved, the integration effort has already
been performed to support OCSP.
-----Original Message-----
From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org]
Sent: Friday, February 25, 2005 8:24 PM
To: Hallam-Baker, Phillip
Cc: MASS WG
Subject: RE: In response to Housley-mass-sec-review
On Fri, 2005-02-25 at 16:20 -0800, Hallam-Baker, Phillip wrote:
What is either disingenuous or ignorant is to discuss the
problem of
CRL handling without mentioning OCSP which is a technology that has
been operational since 1998 or so. The first version of
Authenticode
included an OCSP component (albeit one based on a now obsolete
standard).
Notes from RFC2560:
X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
---------------------
5. Security Considerations
For this service to be effective, certificate using systems must
connect to the certificate status service provider. In the
event such
a connection cannot be obtained, certificate-using systems could
implement CRL processing logic as a fall-back position.
A denial of service vulnerability is evident with respect
to a flood
of queries. The production of a cryptographic signature
significantly
affects response generation cycle time, thereby exacerbating the
situation. Unsigned error responses open up the protocol to another
denial of service attack, where the attacker sends false error
responses.
The use of precomputed responses allows replay attacks in which an
old (good) response is replayed prior to its expiration date but
after the certificate has been revoked. Deployments of OCSP should
carefully evaluate the benefit of precomputed responses against the
probability of a replay attack and the costs associated with its
successful execution.
Requests do not contain the responder they are directed to. This
allows an attacker to replay a request to any number of OCSP
responders.
The reliance of HTTP caching in some deployment scenarios
may result
in unexpected results if intermediate servers are incorrectly
configured or are known to possess cache management faults.
Implementors are advised to take the reliability of HTTP cache
mechanisms into account when deploying OCSP over HTTP.
-----------------
The review only mentioned the problems required to frequently
poll Certificate Revocation Lists (CRL). Whether done as a
batch process, or as a poll (as indicated within the review),
this added overhead would be problematic. The concern was
with respect to the size of this data, in addition to added
traffic. In a future draft, I will add a reference to
RFC2560 to address your concern of not being comprehensive.
This is still compared to a mechanism, where in the majority
of cases, no query for a revocation status would be required.
Where a query is made, it would involve a single address
record when the account has been revoked, and no record
otherwise. The signature had already been confirmed, so this
mechanism only confirms whether the particular account
remains valid when the message is from a foreign domain.
This is to prevent the potential for a canceled account
staging a replay attack.
-Doug
-----Original Message-----
From: Mark Baugher [mailto:mbaugher(_at_)cisco(_dot_)com]
Sent: Friday, February 25, 2005 6:02 PM
To: Hallam-Baker, Phillip
Cc: 'Douglas Otis'; Dave Crocker; MASS WG
Subject: Re: In response to Housley-mass-sec-review
I think it's disingenuous to claim that MASS PKI problems
have been
solved when nothing on this scale has ever been deployed.
Mark
On Feb 25, 2005, at 1:07 PM, Hallam-Baker, Phillip wrote:
Perhaps you should take the time to study the
developments in PKI
since 1995 before publishing the draft.
In particular you should look at OCSP which entirely eliminates
the issues you raise wrt CRL size and has been deployed at very
large
scale. You
should
also look at XKMS which has similar operational
requirements to OCSP
but
provides support for the complete key lifecycle and
eliminates the
need for
certificates.
Clearly a key centric PKI that is built on the legacy
DNS system
is
not going to be as satisfactory as a PKI as a purpose built Web
Service such as XKMS. There is however no reason why we
cannot use DNS
for the cases it can
support and migrate to XKMS for more comprehensive support.
Given that certificate revocation technology is built
into Windows
since Win 2000 the CA industry is well aware of the operational
difficulties raised by
CRLs.
-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
Douglas Otis
Sent: Friday, February 25, 2005 3:30 PM
To: Dave Crocker
Cc: MASS WG
Subject: Re: In response to Housley-mass-sec-review
Here is a first pass at putting together a document. Any
feedback is
welcome.
As this was completed beyond the IETF draft cutoff date,
these links
reference the draft.
http://www.kelkea.com/ietf/draft-otis-mass-reputation-00.html
http://www.kelkea.com/ietf/draft-otis-mass-reputation-00.txt
-Doug