[IPsec] ikev2bis issue #187: EAP introduction wording

The first paragraph of 3.16 now says: The Extensible Authentication Protocol Payload, denoted EAP in this document, allows IKE SAs to be authenticated using the protocol defined in RFC 3748 and subsequent extensions to that protocol. The full set of acceptable values for the payload is defined

[IPsec] ikev2bis issue #185: What do to if you don't ignore INITIAL_CONTACT

s2.4, para 2, says "The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request or response, not as a separate exchange afterwards; receiving parties MAY ignore it in other messages." What should receiving parties do if they *do* receive it and *don't* ignore it? Since it '

[IPsec] ikev2bis issue #186: Generating and accepting which types?

s3.5, para after ID Field types table: 'Implementations SHOULD be capable of generating and accepting all of these types.' Does 'all' here mean the four types in the previous sentence or 'all' the types in the full table? ___ IPsec mailing list IPsec@ie

[IPsec] ikev2bis issue #184: Interaction of rekeying of the IKE_SA and windows

s2.3: Should there be some discussion of the interaction of rekeying of the IKE_SA and windows? Presumably a rekey message should not be actioned until all previous messages have been responded to. Likewise receiving a Message ID with a sequence number bigger than that in the rekey message shoul

[IPsec] ikev2bis issue #183: Replace "X.509" with "PKIX" throughout?

We use "X.509" when we probably mean "PKIX". That is, we only care about the PKIX profile of X.509, not just the base X.509 spec. However, X.509 appears in some of the protocol element names. Can we change it throughout to PKIX, or are we stuck with the old name? ___

[IPsec] ikev2bis issue #182: Marking CP() as optional in early sections

Sean Turner asks: Sec 1.2/2.19: Shouldn't "[CP()]" be in message 3 and 4 in Section 1.2? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] ikev2bis issue #181: Section 2.4 unclear on Child SA failing

Section 2.4 says "If Child SAs can fail independently from one another without the associated IKE SA being able to send a delete message, then they MUST be negotiated by separate IKE SAs". It is not clear what this means. Does it apply to implementations? If so, how can an implementation know wh

[IPsec] draft-ietf-tsvwg-ecn-tunnel: backwd compat RFC4301 update

IPsecME folks, I would like to draw your attention to from the transport area w-g. You may recall I gave early warning of this work to the Security Area open meeting back in July'09. A formal SecDir review has just been request

Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

Hi Raj, No, RFC 5685 tried for generality without defining the usage scenario in advance, and this attempt failed. The solution cannot be used gateway-gateway, because it depends on the (arbitrary) initiator/responder distinction. Thanks, Yaron On 30.3.2010 15:43, Raj Singh wrote:

Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

Hi Yaron, You are saying the same things what i am saying, then i am not able to understand how its counter example? The point i want to make here, "We can emphasize the main use case scenario the draft, but protocol should have a space for generality". According to me RFC - 5685 is good example o

Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

Hi Raj, this in fact is the perfect counter-example: RFC 5685 started out with the client-gateway scenario, and when we woke up to see how it can be generalized to the symmetric gateway-gateway case, it was too late. Hence Sec. 10, which says that the resulting protocol is a very partial solu