[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems with SKIP

> From: Steve Bellovin <smb@research.att.com>
> SKIP's in-band key negotiation makes it difficult to revoke a
> compromised certificate.  A host may have a cached copy of the old
> certificate and to use when computing the long-term key Kij.  But
> such packets will be rejected by the recipient, since they won't
> decrypt properly.  Nor will either party know why, unless the
> receiving machine sends a special bounce message any time decryption
> fails, if that happens between the revocation time and the normal
> expiration time of the certificate (and that period could be several
> years, per the draft).


CRL distribution is supposed to be much more frequent than certificate
validity periods. If your CRL has expired, (and the CRL format
that is specified in SKIP I-D is the same type as in RFC 1422, where
there is a "next-issue-date" field") then, possibly under policy
control, you stop operation. One doesn't wait for the expiry
date of the certificate if the CRL directory has been suppressed
through denial-of-service. If one doesn't have an up-to-date
CRL, then the certificate cannot be considered to be any good.

This is precisely why there is a "next-issue-date" in the
RFC 1422 CRL format. Once a new CRL is issued, all cached
certificates are purged from any local cache (including
cached Kijs).

Note that far more serious attacks than denial-of-service
are possible if a certificate has been compromised and
CRLs are suppressed, including outright impersonation.

> It isn't clear how one side can force the use of different session
> keys for each connection between a given pair of hosts.  While it
> can choose different session keys itself, there is no way for it
> to tell the other side to do so.  A number of attacks are possible
> under these circumstances, especially if a stream cipher is used.

The fact that each source of encrypted traffic should use different
traffic keys is an important part of SKIP. SKIP accomplishes this not 
just for the case of a pairwise connection, (the easy part) but also
for the far trickier case of multicast traffic.

This is accomplished by each source of traffic (for both unicast
and multicast IP) to randomly generate its own traffic key encrypted
in either Kij for the case of unicast IP or the Group Interchange Key
(GIK) for the case of multicast IP.

So, e.g., in case of a TCP connection, each side automatically
uses different keys for each direction of encrypted traffic,
allowing the use of any kind of stream cipher and eliminating
the possibility of key-stream reuse scenarios.