Subject: RE: Reminder: last call for PIC in the IPSRA WG

From: "Andrew Krywaniuk" <[email-masked]>
Date: Mon, 1 Oct 2001 19:30:24 -0400

In terms of the DoS potential of the Internet, I think we've only seen the
tip of the iceberg. It's definitely better to have some kind of cookie
exchange. I believe William brought up the lack of DoS protection at the
IETF meeting, along with a question about the hash calculation.

I also wonder about the hash calculation. When Hugo was asked why we're not
using the revised hash in PIC, he replied that the situation that motivated
the development of revised hash in IKE doesn't exist in PIC. I guess that's
true (PIC says you can't include notify or vendor id payloads until after
the first hash has been sent), but I still wonder what's the point? Is there
any advantage to the particular hash calcuation that is described in PIC?

Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Markus Stenberg
> Sent: Monday, September 17, 2001 8:35 AM
> To: [email-masked]
> Subject: Re: Reminder: last call for PIC in the IPSRA WG
>
>
>
> [email-masked] (Paul Hoffman / VPNC) writes:
> > Hi again. Just a reminder that we are in the middle of the PIC last
> > call in the IPSRA WG. The last call ends at the end of September
> > unless significant changes are needed to the spec.
> >
> > It has been pretty quiet here, and maybe that is good.
>
> I was also on vacation (four weeks :>), which delayed
> somewhat this mail. I
> didn't want to start discussion while people were still in
> Finland in the
> VPN workshop, and I regrettably had to leave workshop's
> summary session
> before I could poll it locally.
>
> I still personally feel that with the discussion about s-o-IKE, and
> _especially_ the discussions regarding aggressive/main(/base)
> mode in IPsec
> WG, it might be bad idea to select aggressive-like approach for PIC.
>
> Why do we want to perform significant work on basis of a packet from a
> source which we haven't even verified exists and really wants
> to talk to
> us?
>
> This could be circumvented (at least) by changing the
> exchange from 3 to 4
> messages and styling it after base mode instead of aggressive mode.
>
> If someone else agrees, feel free to point it out; if it's
> just me, I'll
> go back to my corner :>
>
> > --Paul Hoffman, Director
> > --VPN Consortium
>
> -Markus
>
> --
> Markus Stenberg ([email-masked]) of SSH Communications
> Security (www.ssh.com)
>

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 17 Oct 2001 00:23:44 +0200 (IST)

Dear Markus,

Better later than never...

One can add to PIC some DOS protection via two extra initial messages
(this is what I said during the London ietf meeting when asked about
it). Adding these messages is quite straightorward from the point of view
of specification (the messages would carry a cookie from client to server
and one from server to client -- the last one being a stateless cookie a
la Karn) but it certainly adds performance and protocol complexity.
Having lacked explicit requirements for such measures we settled for
simplicity and less performance penalty.

If you obtain consensus to add this stuff, then it is doable.

As for your suggestion to use base mode: this solution would be
inappropriate here. It requires a responder's state anyway and its main
advantage in the context of IKE is lost here. This advantage is that the
responder can do a (rleatively cheap) RSA sig verification before it
performs its own signature and the g^xy DH exponentiation. However, in PIC
there is no signature from the client at all, so this mechanism of base
mode does not aply here.

Thanks for the feedback.

Hugo

On 17 Sep 2001, Markus Stenberg wrote:

> I was also on vacation (four weeks :>), which delayed somewhat this mail. I
> didn't want to start discussion while people were still in Finland in the
> VPN workshop, and I regrettably had to leave workshop's summary session
> _especially_ the discussions regarding aggressive/main(/base) mode in IPsec
> source which we haven't even verified exists and really wants to talk to
> us?
> 
> This could be circumvented (at least) by changing the exchange from 3 to 4
> If someone else agrees, feel free to point it out; if it's just me, I'll
> go back to my corner :>
> 
> > --Paul Hoffman, Director
> > --VPN Consortium
> 
> -Markus
> 
> -- 
> Markus Stenberg ([email-masked]) of SSH Communications Security (www.ssh.com)
>

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 17 Oct 2001 00:29:24 +0200 (IST)

Dear Andrew,

> IETF meeting, along with a question about the hash calculation.

I referred to the DoS protection via cookies in my previous message 
to Markus. It is doable, the question is if there is consensus.

> any advantage to the particular hash calcuation that is described in PIC?

In PIC we have HASH_R in the second message, and HASH in second, third and
fourth messages. HASH is used to authenticate each of the EAP payloads
(except payload headers -- see (*) below) so it serves for providing the 
cryptographic authentication of the exchanged information and does 
not require further complication (e.g. it does not require including 
packets from previous messages as suggested in the revised-hash draft).

As for HASH_R we are going to include the full ISAKMP headers from both
messages 1 and 2 under HASH_R which cover CKY-I and CKY-R as in IKE
but also the Major and Minor numbers.
ANother important change in the  calculation of HASH_R in PIC 
is that it corrects the IKE's typo of missing SA_r from 
the authenticated information under HASH_R.  Moreover, in PIC also 
SA_i is included under HASH_R so the client can verify that its SA 
proposals were not modified in route.

Hugo

(*) This, however, requires one "design disclaimer" that appears in the
PIC document (end of section A.1 in the 03 draft):

 ``Another design decision made in order not to change the regular ISAKMP
   processing is to apply authentication (under the HASH payload) 
   to base payloads only and not to payload headers. Authenticating 
   all bits, including headers, would have been a better approach but 
   also in this case we have favored ISAKMP compatibility. ''

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Tue, 16 Oct 2001 19:48:29 -0400

I have no doubt that the hash as it exists in PIC is sufficient. I was
merely questioning why you would want to do it this way when the revised
hash method is easier. I have implemented both for IKE and the advantage of
the revised method is that you can create a single function which
hashes/verifies any ISAKMP packet regardless of its type. Plus, it accounts
for the future use of any header flags, notify payloads, etc. which are
security-sensitive.

With IKE right now, you have to store parts of previous packets for future
use in hash calculations. You either have to store them in raw format (which
is inconvenient) or in parsed format, in which case there is potential for
error when you reconstruct them. (Imagine if ESP had to selectively include
different parts of the packet in order to calculate the hash... oh wait,
that's AH.)

Andrew

> [mailto:[email-masked]]On Behalf Of Hugo Krawczyk
> Sent: Tuesday, October 16, 2001 6:29 PM
> To: Andrew Krywaniuk
> Cc: 'Markus Stenberg'; [email-masked]
> Subject: RE: Reminder: last call for PIC in the IPSRA WG
>
>
>
> Dear Andrew,
>