Black David writes:
> > If it means all the listed types, the sentence should be changed to
> "Implementations SHOULD
> > also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and
> ID_DER_ASN1_GN."
>
> Which I think amounts to a SHOULD for certificate support. Is there a
> good reason to
Paul Hoffman writes:
> Section 3.5 lists a bunch of ID types (ID_IPV4_ADDR, ID_FQDN,
ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and
ID_KEY_ID), and then says:
>
> Two implementations will interoperate only if each can generate a type of
ID acceptable to the other. To assure maxi
> > 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
At 9:17 PM -0500 1/21/10, wrote:
>Paul,
>
>> What does "Implementations SHOULD be capable of generating and
>accepting all of these types" mean?
>
>It's hair-splitting time ...
>
>> To assure maximum interoperability, implementations MUST be
>configurable to send at least one of
>> ID_IPV4_ADDR, I
Paul,
> What does "Implementations SHOULD be capable of generating and
accepting all of these types" mean?
It's hair-splitting time ...
> To assure maximum interoperability, implementations MUST be
configurable to send at least one of
> ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MU
Section 3.5 lists a bunch of ID types (ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR,
ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID), and then says:
Two implementations will interoperate only if each can generate a type of ID
acceptable to the other. To assure maximum interoperability, imp
> > > 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 third bu
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,
In the sectioon 2.9 the "SHOULD" requirement was removed for the
very specific traffic selector as fist traffic selector.
I think that "SHOULD" requirement needs to be kept, as it affects
interoperability, as if other end does not include that triggering
packet then certain policies cannot interop
At 5:05 PM +0200 1/21/10, Tero Kivinen wrote:
All changes made other than the following.
>--
>
>Section 2.8.2 there was removed paragraph:
>
> However, there is a twist to the other case where one rekeying
> finishes
At 11:08 AM +0200 1/21/10, Tero Kivinen wrote:
>Yaron Sheffer writes:
>> > 1.4.1: the last paragraph springs a surprise by defining the behavior
>> > of IKE SA deletion while discussing an unlikely "messing up" of Child
>> > SAs. IKE SA deletion deserves its own subsection.
>> >
>> > [[ Response: i
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
It seems my number of lines in comment emails is going down (it was
1300 lines, then 950 lines, and now only 240 lines) so hopefully we
are getting closer to the get ready...
--
In section 2.6 there is typo:
Also,
Hi
I would like to have information on aes-xcbc-mac96 hashing using
multiple ring entries.
I need to implement MD5, SHA-1 and AES-XCBC-MAC96 hashing algorithms
using multiple ring entries of the IPSec block.
For md5 and sha-1 the hash results i get, tally with that of results
generated when done
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
Also add at the end of the relevant paragraph of 2.16: "If the exchange is
terminated with EAP Failure, an AUTHENTICATION_FAILED notification is not sent."
Thanks,
Yaron
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Tero Kivine
Yoav Nir writes:
> We do have this:
>
> The
>responder MAY at any time terminate the IKE exchange by sending an
>EAP payload containing the Failure message.
>
> I guess "terminate" means that the initiator does not send any m
Yaron Sheffer writes:
> > 1.4.1: the last paragraph springs a surprise by defining the behavior
> > of IKE SA deletion while discussing an unlikely "messing up" of Child
> > SAs. IKE SA deletion deserves its own subsection.
> >
> > [[ Response: it is optional behavior and makes sense. If you want
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
21 matches
Mail list logo
