fman
> Subject: Re: [IPsec] Issue #139: Keying material taken in the order for
> RoHC
>
> Valery Smyslov writes:
> > Paul Hoffman writes:
> > > All good points, Valery. Here's another attempt; please check
> carefully.
> > >
> > >A single CHI
Valery Smyslov writes:
> Paul Hoffman writes:
> > All good points, Valery. Here's another attempt; please check carefully.
> >
> >A single CHILD_SA negotiation may result in multiple security
> >associations. ESP and AH SAs exist in pairs (one in each direction),
> >so two SAs are cre
Paul Hoffman writes:
> All good points, Valery. Here's another attempt; please check carefully.
>
>A single CHILD_SA negotiation may result in multiple security
>associations. ESP and AH SAs exist in pairs (one in each direction),
>so two SAs are created in a single Child SA negotia
All good points, Valery. Here's another attempt; please check carefully.
A single CHILD_SA negotiation may result in multiple security
associations. ESP and AH SAs exist in pairs (one in each direction),
so two SAs are created in a single Child SA negotiation for them.
Furthermore, Ch
Paul Hoffman writes:
I have closed the issue, but wanted to post my new text because it
rearranges some of Valery's proposed text. Please reply on this thread if
you think I have muffed it.
A single CHILD_SA negotiation may result in multiple security
associations. ESP and AH SAs exist i
I have closed the issue, but wanted to post my new text because it rearranges
some of Valery's proposed text. Please reply on this thread if you think I have
muffed it.
A single CHILD_SA negotiation may result in multiple security
associations. ESP and AH SAs exist in pairs (one in each d
> > So, I think it is better to rely on RFC4301 here and leave 3rd bullet
out.
>
> That also works for the GCM and CCM examples because their necessary
details
> are already specified in the GCM and CCM RFCs. GCM and CCM actually take
salt
> values for nonces (as opposed to the nonces themselves f
> > > This leaves out the third bullet, i.e. "3) if single protocol has both
> > > encryption and authentication keys, the encryption key is taken first
> > > and the authentication key after the encryption key."
> >
> > This bullet is probably superfluous and incomplete.
> >
> > First, RFC4301 alr
Unsubscribe
- Original Message -
From: ipsec-boun...@ietf.org
To: Valery Smyslov
Cc: IPsecme WG ; Yoav Nir ; Paul Hoffman
Sent: Thu Jan 21 15:47:14 2010
Subject: Re: [IPsec] Issue #139: Keying material taken in the order for RoHC
Valery Smyslov writes:
> > This leaves out the
Valery Smyslov writes:
> > This leaves out the third bullet, i.e. "3) if single protocol has both
> > encryption and authentication keys, the encryption key is taken first
> > and the authentication key after the encryption key."
>
> This bullet is probably superfluous and incomplete.
>
> First,
Tero Kivinen writes:
> I think this generic rule was good in the RFC4306, as it makes it
> definite how keying material is derived even when there are multiple
> extensions present. Removing that in the IKEv2bis does not gain us
> anything, but will remove text that is then needed to be copied to
Yoav Nir writes:
> I think extensions such as RoHC that change (or extend) the way
> keying material is generated, should and do specify how it is done.
> Leaving that text there becomes a recommendation for future draft
> writers, which I think is superfluous.
RoHC has text which explains how t
Hi Yoav,
> I think extensions such as RoHC that change (or extend) the way keying
material is generated, should and do specify how it is done.
I don't think so. If multiple protocols are involves, the way how (in which
order)
each of them obtains its key from IKE keying material is in general out
I think extensions such as RoHC that change (or extend) the way keying material
is generated, should and do specify how it is done. Leaving that text there
becomes a recommendation for future draft writers, which I think is
superfluous.
I think we should leave the text as it is.
On Jan 19, 20
14 matches
Mail list logo
