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
One of the differences between RFC 4306 and the IKEv2bis draft is in
Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the
IKEv2bis draft indicates the following:
In Section 2.17, removed "If multiple IPsec protocols are negotiated,
keying material is taken in the order in
15 matches
Mail list logo
