[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Reminder: last call for PIC in the IPSRA WG
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
-------------------------------------------
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 Hugo Krawczyk
> Sent: Tuesday, October 16, 2001 6:29 PM
> To: Andrew Krywaniuk
> Cc: 'Markus Stenberg'; ietf-ipsra@xxxxxxxx
> Subject: RE: Reminder: last call for PIC in the IPSRA WG
>
>
>
> Dear Andrew,
>
> 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.
>
> 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. ''
>
>
>
> >
> > 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: 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)
> > >
> >
> >
>
>
>
>