Re: [IPsec] Secure Crash Discovery for IKEv2

[Tero Kivinen <[e-mail]>]

Pratima Sethi writes:
> Is there a specification of Birth Certiifcates that you can point us
> to ?

No, that was never written to draft form of its own. It was presented
on this list by Bill Sommerfeld long time ago. It has been explained
in few drafts quite shortly, for example in the
http://tools.ietf.org/html/draft-ietf-ipsec-soi-features-01 section
3.5:

----------------------------------------------------------------------
3.5 Birth certificates

Assume Alice and Bob have an SA established, and that Bob crashes and
restarts. Alice will send a packet into an SA that Bob doesn't know
about. Birth certificates are a method for letting Alice know that the
SA is no longer alive.

It is desirable that such a mechanism be inexpensive for Bob. If a
mechanism required a lot of computation, for instance, having Bob sign a
customized message saying, "This SA didn't decrypt properly. Perhaps
it's because it's a reused SA number from before I crashed" or "unknown
SPI", then there is an easy DOS attack on Bob's limited computation by
sending him bogus messages. If Bob sends totally unauthenticated
messages, it is difficult for Alice to act on them, since an active
attacker could send her "no such SPI" messages to cause her to close
connections.

The idea of a birth certificate, originated in the IPsec Working
Group by Bill Sommerfeld, is that Bob should have a monotonically
increasing number that increases each time Bob restarts. When Bob
restarts, he signs a message saying, "this is my incarnation number".
When Bob creates an SA, Bob optionally sends his birth certificate.
Alice can optionally keep this certificate with her SA. Then, if Alice
ever receives an error message from Bob with a birth certificate with a
higher incarnation number, she can remove all SAs associated with Bob's
previous incarnation.

This mechanism is somewhat overlapping with the "initial-contact"
mechanism in IKEv2. Discussion in the WG suggested that birth
certificates could replace initial-contact, but some people said that
both were valuable.
----------------------------------------------------------------------

Or from http://tools.ietf.org/html/draft-ietf-ipsec-ikev2-rationale-00
section 3.1:

----------------------------------------------------------------------
   - adding in Bill Sommerfeld's "birth certificate" idea. In this idea
   Bob keeps a number in nonvolatile memory that increments each time
   the node restarts. When Bob restarts, he signs a "birth certificate"
   stating what the value of that counter is. This birth certificate is
   transmitted as a payload in message 4. Alice keeps this value. If Bob
   ever receives an ESP packet that doesn't decrypt properly or with an
   unknown SPI, he responds to that packet with his birth certificate.
   If the recipient has an SA for Bob with an older birth certificate,
   this lets them know Bob has restarted and forgotten state for that
   SA. We decided not to add that to this version of the draft, although
   we think it is a good idea, until it's been written up in a separate
   draft and there has been an opportunity for people to understand it
   and give feedback.
----------------------------------------------------------------------

I think this was the original email message explaining them on the
ipsec-list http://www.vpnc.org/ietf-ipsec/00.ipsec/msg01415.html:

----------------------------------------------------------------------
Message-Id: <[e-mail]>
In-reply-to: Your message of "Mon, 07 Aug 2000 15:55:21 PDT."
             <[e-mail]> 
From: Bill Sommerfeld <[e-mail]>
To: Scott Fanning <[e-mail]>
cc: Derek Atkins <[e-mail]>, [e-mail],
        "Scott G. Kelly" <[e-mail]>, Skip Booth <[e-mail]>,
        Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: Heartbeats Straw Poll 
Date: Mon, 07 Aug 2000 19:09:50 -0400
Reply-to: [e-mail]

> Maybe we need a "death certificate" CA :-) 

Heh.  Actually, one of the ideas I'm kicking around:

If we have the system sign a "birth certificate" when it reboots
(including a reboot time or boot sequence number), we could include
that with a "bad spi" ICMP error and in the negotiation of the IKE SA.

This pushes the burden of reestablishing state to the end which
already thinks it has shared state and has traffic it wants to send.

The system which is receiving packets to unknown spi's merely has to
respond with a simple message which involves no real-time cryptography
(it should, of course, be rate limited).

The system receiving the error message can discard it if it doesn't
correspond to existing state or if it's "old news" (i.e., you get
replay protection); if it's not old news, you can rate-limit how often
you attempt to verify the signature.

I *think* this is relatively resistant to replay and DoS...

                                        - Bill
----------------------------------------------------------------------

>  From what I understand ,Bob generates a single certificate when he 
> reboots, and will add that as  a birth certificate payload, to the 
> invalid_spi notification. If  Bob only generates one certificate 
> independent of the client Alice, Mallet( the MitM) can snoop and learn 
> the birth certificate and replay this to any Alice connected to Bob. How 
> does Alice trust that the information is a fresh valid packet generated 
> by Bob and not a "constructed" packet from an attacker.

The Bob also sent that same certificate with the counter (or
timestamp) inside of it when it created the SA. The Alice will receive
the birth certificate, and first check if the counter is same than
before. If it is, then it knows this is old news, and it can simply
ignore the notification. If it has larger incarnation number than the
one used when creating the SA, then it can validate the signature of
the certificate and if that is valid, then it knows that Bob has
rebooted since they created the SA, thus Alice can safely remove all
IKE and IPsec SAs between her and Bob. As only Bob can create valid
signatures, and Bob only does that after reboot Alice can know for
sure that Bob has rebooted.

The incarnation number can be timestamp or simple running counter, the
only property that is required is that it cannot go backwards, and it
has bigger number than it had before every time the machine is booted.
As certificates do require clock or similar already, that same clock
can be used here too.
-- 
[e-mail]
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec