[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Reminder: last call for PIC in the IPSRA WG
On Mon, 1 Oct 2001, Andrew Krywaniuk wrote:
> 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 referred to the DoS protection via cookies in my previous message
to Markus. It is doable, the question is if there is consensus.
> 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?
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.
(*) 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. ''
> 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: owner-ietf-ipsra@xxxxxxxxxxxxx
> > [mailto:owner-ietf-ipsra@xxxxxxxxxxxxx]On Behalf Of Markus Stenberg
> > Sent: Monday, September 17, 2001 8:35 AM
> > To: ietf-ipsra@xxxxxxxx
> > Subject: Re: Reminder: last call for PIC in the IPSRA WG
> > paul.hoffman@xxxxxxxx (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 (stenberg@xxxxxxx) of SSH Communications
> > Security (www.ssh.com)