Yoav,
I think preserving the history is worthwhile. I'm fine with moving section
7 to an appendix. With
that said Tero will still object to the text that would become A1.4
(currently 7.4). The text in
Section 7.4 represents our opinion which is not the same as his. I think
the text should be
m
I agree with Tero that it is unsafe to assume how a load balancer decides
to distribute traffic. Since section 9.4 (previously 10.4) is in the
Security Considerations section it seems reasonable to me that we'd warn
that the algorithms in 5.1 and 5.2 should not be used in cases where load
balancin
paragraph in my append. I
had actually intended to cut and paste the last paragraph of 9.4 and I now
see that I cut and paste the next to last paragraph in section 9.4 :>).
Dave Wierbowski
From: Scott C Moonen/Raleigh/IBM@IBMUS
To: David Wierbowski/Endicott/IBM@IBMUS
Cc:
I'm not sure what Frederic means by this statement should "be moved under
Security Considerations." Section 9.2 is already in the Security
Considerations section.
As far as his proposed text, I feel that Scott's text does a better job
describing the concern. Frederic's own text does not help wit
I agree with Tero that the section is confusing and very difficult to
follow. I have taken a stab at rewording it. I think this still
incorporates the blending of the two approaches that Paul attempted, but
flows better and makes it easier to understand. I'm not sure it addresses
all of Tero's
In IKEv1 sending empty certificate request was agreed to mean "give me your
cert, any cert". Does this same concept apply to IKEv2? RFC 4306 does not
mention the notion of an empty cert request payload. Section 3.6 of RFC
4306 implies that one may not need to send a certificate request in orde
I do not believe the algorithm below is consistent with what was said in
section 5.11.4 of RFC 4718. Section 5.11.4 of RFC 4718 said:
5.11.4. Simultaneous IKE_SA Rekeying
Probably the most complex case occurs when both peers try to rekey
the IKE_SA at the same time. Basically, the text
Ticket #9 says"If the authentication fails in such ways that the entries
cannot create IKE SA (authentication failure or similar), then the response
will be unencrypted, unauthenticated notify." Back in January there was
additional discussion about this issue. Several people supported sending
t
Tero Kivinen writes:
> Michael Richardson writes:
> > Yoav Nir wrote:
> > > Hi Raj
> > >
> > > Matt is correct. There is no way in IKEv2 to do a phase1-only
exchange,
> > > and then wait for traffic to establish the child SAs.
> > >
> > > While we do establish an IKE SA if the piggy-backed child S
> Tero said:
>
> For the X.509 bundle I think the format is more clear and only one
> CERT payload is sent containing hash and url of all certificates and
> crls needed (and first certificate there is the one used for AUTH
> payload).
Tero, I do not agree that it is more clear that only one CERT
If I do not send an HTTP_CERT_LOOKUP_SUPPORTED notify is it valid for my
peer to send me a certificate payload with a hash and URL encoding (i.e. 12
or 13)? I do not see any language in RFC 4306 or 4945 that states the peer
MUST NOT send a certificate payload with a hash and URL encoding in this
At 9:30 AM -0400 5/22/09, David Wierbowski wrote:
>If I do not send an HTTP_CERT_LOOKUP_SUPPORTED notify is it valid for my
peer to send m
Paul Hoffman
To
Sent by: David Wierbowski/Endicott/i...@ibmus
ipsec-boun...@iet
>).
Dave Wierbowski
Paul Hoffman
To
Sent by: David Wierbow
Yaron,
Your proposed reordering seems fine to me. I agree with moving section 1.7
to an appendix. Moving sections 1.2-1.5 to sections 2-2.4 does not add a
great deal of value, but does make sense. I think either way is fine. I
have no preference realtive to the section 1.2-1.5 move.
Dave Wier
We use multiple certificate payloads when using X.509 Certificate -
Signature (4) encoding.
I do not really see how this could be questioned. RFC 4306 clearly says
X.509 Certificate - Signature (4) encoding contains a single certificate as
pointed out below. The logical conclusion is that if y
I agree with Tero that Yoav's proposed text adds clarity and effectively it
does not add a new MUST; however, to address Paul's concern can we just
change the words "MUST be" to the word "are" or lower case "should be?"
For example:
o X.509 Certificate - Signature (4) contains a DER encoded X
>David Wierbowski writes:
>> I agree with Tero that Yoav's proposed text adds clarity and effectively
it
>> does not add a new MUST; however, to address Paul's concern can we just
>> change the words "MUST be" to the word "are" or lower
In a recent append Tero said:
>Then the responder is already going against the RFC4306 which says
>"Certificate revocation checking must be considered during the
>chaining process used to select a certificate. " meaning the responder
>cannot send certifiate which itself considers revoced. Only ca
Tero, thanks for the comments and the clarification on how to read a lower
case must. I do have a few more comments.
>So implementations cannot just search uppercase "MUST/SHOULD/MAY"
>texts and assume it is enough to make sure those are correct. It also
>needs to do what the text says...
>
I th
>Yes, I will soften the language a bit, but I won't mention a DELETE
payload. If some implementations do it.
>others may come to expect it. We don't want to encourage that by
suggesting that it's a good idea.
Yoav, Why is it a a bad idea to include a DELETE payload in this case?
Dave Wierbowski_
Yoav Nir
To: David Wierbowski/Endicott/i...@ibmus
Cc: "ipsec@ietf.org" , Keith
Section 3.6 of ikev2bis-04 says, "Certificate payloads SHOULD be included
in an exchange if certificates are available to the sender unless the peer
has indicated an ability to retrieve this information from elsewhere using
an HTTP_CERT_LOOKUP_SUPPORTED Notify payload."
Section 3.7 of ikev2bis
Section 3.1.5 of RFC 4945 states that when generating an ID type of
ID_DER_ASN1_DN that "implementations MUST populate the contents of ID with
the Subject field from the end-entity certificate, and MUST do so such that
a binary comparison of the two will succeed." Section 3.1.5 is specific to
IK
From: Yoav Nir
To: David Wierbowski/Endicott/i...@ibmus
>Tero states:
> The basic case is where both ends notice this is simultaneous
> rekey, and can delay moving of the CHILD_SAs until they know which
> one wins. The more complex case happens where there is dropped
> packets and one end does not detect simultaneous rekey until it has
> already f
>Tero Stated:
>
> Deleting the IKE SA immediately makes it impossible to know what
> happened to other exchanges going on the same IKE SA. Waiting for 30
> seconds or so after rekey would allow those other exchanges to finish
> before the old IKE SA is deleted.
>
> The current IKEv2 docum
I posted this a last week and have not seen any comments:
Section 3.6 of ikev2bis-04 says, "Certificate payloads SHOULD be included
in an exchange if certificates are available to the sender unless the peer
has indicated an ability to retrieve this information from elsewhere using
an HTTP_CERT_L
>> I agree with what you stated here, but I feel you are addressing
something
>> that is not limited to a simultaneous rekey of the IKE SA. It deals with
>> any
>> rekey of an IKE SA. In my opinion the text is misplaced and should be in a
>> section that deals with handling of outstanding exchang
Tero Wrote:
> RFC4718 is informational and tried to clarify things which are not
> clear in RFC4306. Now we are writing standard track document when
> revising RFC4306 and in that case we can even change things specified
> in RFC4306, if needed. In this case I do not think we need to change
> thing
> Sec. 3.7 has:
> The contents of the "Certification Authority" field are defined
only for X.509 certificates, which are types 4, 10, 12, and 13. >
Other values SHOULD NOT be used until standards-track specifications
that specify their use are published.
> This excludes
> Should be added to Sec. 3.6, probably as a new subsection.
> One Hash & URL (H&U) bundle only. Or...
> One Raw RSA key, or...
> One or more cert payloads of either type 4 or H&U (type 12)
I think there are cases where it makes sense to send any combination of
types 7, 12, and 13. I do n
> So the text most likely should say that "For other values the
> certificate authority field contents is not defined, and can be
> anything (or empty) until specifications that specify their contents
> is published."
I do not think they can be anything. I think they need to be empty until
specifi
>> I don't agree with you. Remember, when IKEv2 was being developed,
>> one of the motivations for single self-contained document was complaint
>> from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1
>> was very inconvinient and provoked confusions that led to
interoperability
>> proble
Paul,
I haven't matched Scott's efforts, but I do have some comments:
Comment #1:
Section 1.2 (The Initial Exchanges) has the following sentence, which was
also in RFC 4306.
Payloads that may optionally appear will be shown in brackets,
such as [CERTREQ], indicate that optionally a certi
I think it is reasonable to expect that an IKEv2 bis implementation would
use an IF statement to control sending the new Notify types. If the minor
number was changed an implementation could check the minor version and send
the new notify types when the minor version was 1 and send the notify type
I'm not sure I'm going to buy that garage door opener if I have to wait for
dead peer detection before I can open or close it again :>).
Dave Wierbowski
From: Tero Kivinen
Section 4 of IKEv2bis (and RFC 4306) states:
IKEv2 is designed to permit minimal implementations that can
interoperate with all compliant implementations. There are a series
of optional features that can easily be ignored by a particular
implementation if it does not support that fea
>At 2:03 PM +0200 1/19/10, Tero Kivinen wrote:
>>Paul Hoffman writes:
>>> In section 3.6 we have text which says:
>>>
>>> Certificate payloads SHOULD be included in an exchange if
>>>certificates are available to the sender unless the peer has
>>>indicated an ability to retrieve
>>I agree with the wording Tero has provided and I think that is
>>what the intent of the original text was.
>
>We disagree here. The point of hash-and-URL was to prevent people from
sending certs.
We do not disagree. The point of hash-and-URL is to prevent people from
sending certs and it does.
Section 4 of IKEv2bis states:
A minimal IPv4 responder implementation will ignore the contents of
the CP payload except to determine that it includes an
INTERNAL_IP4_ADDRESS attribute and will respond with the address and
other related attributes regardless of whether the initiat
I agree.
From: Paul Hoffman
To: Tero Kivin
>> I propose removing the sentence, or greatly clarifying it.
>
> For me the current text is very clear, and I do not see how we can
> clarify greatly. This issue usually only affects implementations where
> there are multiple subsystems which can fail independently from each
> other. If the only f
>Yoav Nir writes:
>> 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 neg
>I think we need to mandate that logic you explained there to the RFC.
>The text there does that. It says that you need to keep Child SAs and
>IKE SAs connected, and either all of them work, or none of them work
>(or you might also get delete notifications for those which failed,
>provided the IKE
>> I don't think we need to mandate how a particular situation should be
>> handled. That is up to the implementer. The implementer just needs to
>> know that there is a rule that states the it is not for some child SAs
>> stay up when the IKE_SA disappears. I think the existing text could be
>
>Do you think it is legal to create a system where one Child SA can
>fail in such way that IKE SA cannot send delete notification?
I do not think a robust IKE implementation would allow this.
>
>The current text says it is not legal, but your replacement text
>allows it.
The current bis text is:
>I do not want the current text to be removed just because some people
>think it is not clear as for me it is clear enough and it is something
>that needs to be mentioned, and I have not seen better text to replace
>it.
What about:
If any Child SA fails in such way that a delete notification cann
I agree with Scott and I am also willing to participate in discussion of
the alternatives.
Dave Wierbowski
From: Scott C Moonen/Raleigh/i...@ibmus
To: Yaron Sheffer
Cc: IPsecme WG , ipsec-boun...@ietf.org
Date: 08/05/2010 09:33 AM
Subject:Re: [IPsec] Failure d
I also prefer the QCD draft over the SIR draft. My reasons are similar to
Scott's. I feel the method in QCD is sufficient and the SIR method is
overly complex for the problem at hand. I think SIR would be bigger to
implement and more error prone than QCD. In short I think the SIR method
is a m
Tero writes:
>Paul Hoffman writes:
>> >True, we need some other term for it. Something like the original
>> >IKE_SA_INIT initiator or the party initiating the initial connection
>> >(i.e. triggering). Or simply say that the QCD_TOKENs in INFORMATIONAL
>> >exchanges and rekeys can only be sent by th
Tero writes:
>I do not consider very open protocols which allow all kind of things
>"just for fun" and "in case we someday get scenario which can use it"
>as good thing.
I do not think we are allowing the initiator and responder to
be both a taker and a maker just for fun. There are cases where
e
Tero writes:
>David Wierbowski writes:
>> Tero writes:
>> >I do not consider very open protocols which allow all kind of things
>> >"just for fun" and "in case we someday get scenario which can use it"
>> >as good thing.
>>
>>
I agree that the RFC 2119 language in this section is not appropriate. To
me this is just stating where it makes sense to implement the maker/taker
roles. You also know my opinion about bullet 3. I think an implementer
should be able to decide what roles make sense for their implementation.
Da
Yoav,
Just for posterity, I agree with Scott's suggestion.
Dave Wierbowski
From: Yoav Nir
To: IPsecme WG
Date: 09/30/2010 04:20 PM
Subject:Re: [IPsec] Issue #189 - Reply is not needed for unprotected
message containing QCD
Sent by:ipsec-boun...@ietf
I'm not sure I understand Yaron's concern. Yaron, can you elaborate how a
MITM attacker can easily cause an IKE SA to be reset? I would think he
could only do so if he hi-jacked the original IKE_SA negotiation and is
now impersonating the remote security endpoint. In that case you have
bigger i
I think it is fine to not mandate a particular method of token generation.
I think it is sufficient to provide two recommendations with an applicable
explanation of pros and cons. I do not think this will lead implementers
to make security-critical design mistakes. Most implementers can read an
heffer
To: Yoav Nir
Cc: David Wierbowski/Endicott/i...@ibmus, IPsecme WG
Date: 10/20/2010 10:21 AM
Subject:Re: [IPsec] Issue #194 - Security Considerations should discuss
the threat
In fact I was referring to the whole extension. OK, since you&#x
58 matches
Mail list logo
