I agree, and I don't think you need brackets:
only the first 64 bits of Ni and the first 64 bits of Nr are used in
calculating SKEYSEED, but all the bits are used for input to the prf+ function.
(although I personally did not find it confusing)
On Jan 19, 2010, at 4:25 AM, Paul Hoffman wrote:
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
Hi all
We would like to begin closing IKEv2bis issue at a faster rate than we are
opening new ones. Paul has sent the list a several issues. Some we have
discussed, others - not so much. Here's a summary of three issues, which I
think are ready for closure.
Issue #138 - Calculations involvin
On Jan 22, 2010, at 11:57 PM, Yaron Sheffer wrote:
> The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might
> be helpful.
>
> Here's a first shot (we'll need to add some descriptive text):
>
>SA Payload
>|
>
On Jan 25, 2010, at 1:44 PM, Tero Kivinen wrote:
> Yoav Nir writes:
>
>> Issue #141 - Silently deleting the Child SA after a CHILD_SA_NOT_FOUND
>> ==
>> Section 2.25: "A peer that receives a CHILD
Hi all. Time for another set of issues.
Issue #142 - Difference from RFC 4718 in rekeying IKE SA
Section 2.25.2, "If a peer receives a request to delete a Child SA when it is
currently rekeying the IKE SA, it SHOULD reply as usual, with a
Hasn't this item just been approved by the IESG? Isn't it done?
>
>- A standards-track mechanism that allows an intermediary device, such
>as a firewall or intrusion detection system, to easily and reliably
>determine whether an ESP packet is encrypted wit
Yes, but the heuristics document is not standards-track.
Never mind, I'm not trying to nit-pick our charter proposal.
On Jan 26, 2010, at 11:41 PM, Paul Hoffman wrote:
> At 11:27 PM +0200 1/26/10, Yoav Nir wrote:
>> Hasn't this item just been approved by the I
Hi all.
Combining Pasi's proposed text with Tero's comments I came up with this version.
Is this acceptable to everyone?
Yoav
There are couple of cases when a node receives a packet it cannot
process, but may want to notify the sender about this situation:
o If an ESP or AH packet ar
Hi all
The "offending" paragraph is the following;
An initiator can use port 4500, regardless whether or not there is
NAT, even at the beginning of IKE. When either side is using port
4500, sending with UDP encapsulation is not required, but
understanding received packets with UDP en
from the request. The Response bit is set to 1, and the version
flags are set in the normal fashion.
-Original Message-
From: Tero Kivinen [mailto:kivi...@iki.fi]
Sent: Thursday, January 28, 2010 4:40 PM
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: [IPsec] Closing issue #143 (rewrite
IKE & IPsec treat DHCP like any other protocol.
The selectors for DHCP traffic are a little strange, because the DHCP client
begins by using IP address 0.0.0.0.
Please have a look at http://tools.ietf.org/html/rfc3456
In IKEv2, the CP payload takes over the function of DHCP over IPsec.
Hope th
Hi all.
Yet another batch of issues that we wish to close.
Issue #140 - No SPD entry for transport mode
Section 2.23.1: If the responder doesn't find SPD entry for transport mode with
the modified traffic selectors, and does a lookup with the origin
Me too, but the draft still requires *some* selectors, so the childless draft
is still needed.
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Raj
Singh
Sent: Wednesday, February 03, 2010 5:25 AM
To: Dan McDonald
Cc: IPsecme WG; Paul Hoffman
S
Hi Raj
I don’t think we can specify MUST requirements for the AAA servers, because
we’re not specifying RADIUS or DIAMETER here.
For example in RADIUS, the VPN gateway sends an Access-Request to the server,
which contains the user-name, presumably the same user-name from the IDi
payload.
If t
Hi all.
5 more issues.
Issue #153 - List of EAP methods
3.16: I suggest to remove the table quoted from the EAP RFC. There are dozens
of methods now in the IANA registry, many of which are preferable to the ones
mentioned here.
I agree, especially since we have
, you do need the
user identity.
-Original Message-
From: Alper Yegin [mailto:alper.ye...@yegin.org]
Sent: Thursday, February 04, 2010 3:40 PM
To: Yoav Nir; 'Raj Singh'; Yaron Sheffer
Cc: 'ipsec'
Subject: RE: [IPsec] Fwd: Issue : Regarding EAP identity
Hello,
Why
Hi. Another week, another 5 issues to discuss.
Issue #159 - Payload processing order within messages
=
(3.1) Clarify that the text:
Payloads are processed in the order in which
they appear in an IKE message by invoking
Hi all.
Again we have some more issues:
Issue #147 - Allowing limited retransmission of one-way IKE messages
Either in 2.1 or in 1.5 we should say something about allowing limited
retransmission of the rare one-way IKE messages
Hi.
This is an interesting subject, and perhaps could be a good candidate for
discussion at Anaheim. However, from the narrow perspective of a VPN vendor, I
don't think this issue is very complicated:
- In the first IKE_AUTH request the initiator provides *an* identity. This
could be something
Hi all.
Wer'e down to single digits with the open issues on IKEv2bis. Here are 5 more.
Issue #168 - Identifier field in the EAP payload
3.16: the text here, "...this field MAY be set to any value" implies that the
Identifier field can be constant,
Hi, Syed Ajim.
In future please expand acronyms, because while it's safe to assume that anyone
reading this list knows what an SA is, not all of us are proficient in IPv6
terminology.
Having said that, policies usually have exceptions for protocols, that need to
run in the clear. IKE is an exa
Hi Rahul.
I don’t have a link, but common sense says that there are four things to
consider when choosing algorithms:
- required strength - for example DES is only 56 bits.
- compliance - certain industries have regulations specifying which algorithms
to use.
- performance - of all the accept
Hi all.
There are only three issues this time, because this is the last batch.
Issue #173 - Trigger packets should not be required
===
In a few places in the new section 2.23.1 in IKEv2bis, it says that one
must have a trigger packet when starting
On Feb 19, 2010, at 6:30 AM, Syed Ajim Hussain wrote:
> Hi Yoav Nir & All Group Member
>
> Thanks for your quick response. I think, instead of user takes special
> care by adding extra Rule to allow un-encrypted ND traffic(unicast) ,
> There should be some RFC gu
Hi Raj
On Feb 19, 2010, at 9:25 AM, Raj Singh wrote:
> Hi Yoav,
>
>
>> Issue #174 - How to behave when EAP identity is not send by AAA
>> ===
>> In ikev2bis07
>>
>> - ikev2-bis-07 section 2.16, last paragraph
>>
>>
On Feb 22, 2010, at 5:48 PM, Stephen Kent wrote:
> At 7:22 PM +0530 2/22/10, Syed Ajim Hussain wrote:
>> Hi Steve
>>According to me IPSEC/IKE should have intelligence by by-pass ND Traffic
>>
>>when SA is not ready state without end-user intervention, and same
>>should be accepted by
Hi folks.
5 issues got lost in the system (they were tagged wrong). Hopefully these are
really the last 5.
Issue #132 - Should NO_ADDITIONAL_SAS cover rekeying IKE SAs?
=
In section 1.3 at the end there is text talking about the NO_ADDI
Yes, you can sort-of negotiate DH groups, but you don't have the "New Group
Mode" that we had in section 5.6 or RFC 2409.
So with RFC 4306, you're stuck with only those groups that appear in the IANA
registry, rather than your own pet DH groups.
On Mar 2, 2010, at 10:49 PM, Yaron Sheffer wrote:
Paragraph 5 of section #2:
MUST accept any length that results in proper alignment. It should
be noticed that the ESP [RFC4303] Encrypted Payload requires
Please change "noticed" to "noted".
Other than that, the document looks good enough for implementation.
-Original Message-
Fro
Explaining a joke spoils all the fun, but here goes:
It's not like PKI is working out better for user authentication.
And password-in-https-form is also vulnerable to online dictionary attacks.
Now if they were using TLS-EAP
But that, of course, suffers from excessive layering.
__
Me too.
From: ipsec-boun...@ietf.org [ipsec-boun...@ietf.org] On Behalf Of David
Wierbowski [wierb...@us.ibm.com]
Sent: Monday, March 08, 2010 19:55
To: Paul Hoffman
Cc: IPsecme WG; ipsec-boun...@ietf.org
Subject: Re: [IPsec] Issue #176: What to do with a p
To me it’s pretty obviously the former, although the latter is also true.
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Keith
Welter
Sent: Monday, March 08, 2010 6:18 PM
To: ipsec@ietf.org
Subject: [IPsec] IETFLC comments for dr
On Mar 22, 2010, at 11:18 AM, wrote:
> Summarizing what I said in the meeting:
>
> (1) The performance criteria should include performance with large complex
> secrets (e.g., pre-shared keys), not just the smaller passwords that people
> can reasonably be expected to remember.
>
> This is b
That would be good, but we don't want to madate not using certain modes of
operation when you have a cluster. That would be very counter-productive.
OTOH, because of the replay counter, we've already agreed that an outbound
child SA cannot be shared among members of a load-sharing cluster.
As f
Failure detection by either QCD or SIR takes 1-2 roundtrips, whether this is
subsecond or not depends on round-trip time.
In case of a non-synchronized hot-standby gateway, those 2 roundtrips begin the
moment that the standby gateway becomes active, so the call probably doesn't
get dropped.
In
And thank you for taking the time, Rod.
The linktionary has a pretty good definition, though I don't know if it counts
as "textbook". Same for Wikipedia
http://www.linktionary.com/f/fault_tolerance.html
http://en.wikipedia.org/wiki/Fault-tolerant_system
Anyway, we need to limit the scope of this
On Mar 23, 2010, at 2:31 PM, Melinda Shore wrote:
> On Tue, March 23, 2010 1:20 pm, Yoav Nir wrote:
>> - For the cluster with just one member doing IKE and IPsec, I propose
>> "hot-standby cluster"
>> - For the cluster with several members doing IKE and IPsec, I p
On Mar 23, 2010, at 6:05 PM, Dan Harkins wrote:
>
> Hi,
>
> "hot standby" implies a box sitting ("hot") twiddling its thumbs doing
> little but waiting for another box to fail ("standby"). It's the VRRP
> model.
And that's exactly what I want to describe. Well, not twiddling its thumbs. The
Hi Dan
I am not trying to create a complete taxonomy of cluster types. I should also
note that we don't really have a term for a single "thing" that does IKE and
IPsec. Our documents use terms like "gateway" and "peer", but "gateway" does
not encompass VPN clients and hosts, and "peer" is not j
Hi all
Following Sean's review, Paul has opened 7 issues, which we'd like to close.
I think issues #182, #183, #185 and #186 can be closed immediately.
I think issues #181, #184 and #187 can also be closed, and I have included
below my suggestions. Please take a look and respond if you object
Hi all.
As the previous discussion on this topic showed, the WG would like a more
thorough taxonomy in section 2 of the HA/LS draft. Here's what I have come up
with so far. Please send comments to the list.
2. Terminology
"Single Gateway" is an implementation of IKE and IPsec enforcing a
On Apr 13, 2010, at 1:17 PM, Yaron Sheffer wrote:
> Looks good. A few comments down below.
>
> Yaron
>
> On Tue, 2010-04-13 at 11:49 +0300, Yoav Nir wrote:
>>
>> "Fault Tolerance" is a condition related to high availability, where
>> a
On Apr 13, 2010, at 4:42 PM, Yaron Sheffer wrote:
> [snip]
"Failover" is the event where a one member takes over some load from
some other member. In a hot standby cluster, this hapens when a
standby memeber becomes active due to a failure of the former active
member, or
Begin forwarded message:
> From: IETF I-D Submission Tool
> Date: April 14, 2010 8:21:14 PM GMT+03:00
> To: Yoav Nir
> Subject: New Version Notification for draft-ietf-ipsecme-ipsec-ha-01
>
>
> A new version of I-D, draft-ietf-ipsecme-ipsec-ha-01.txt has been
> s
On Mar 22, 2010, at 6:44 PM, wrote:
> This is probably a small thing, but in general the term "cluster"
> implies at least some degree of shared state among cluster members.
> I understand that there's some suggestion of that in saying that
> a cluster protects the same domain but there's really
Hi.
It's true that the standard is more geared to full implementations than those
minimal implementations, but in this case there really is no solution.
The minimal implementation can delete the IKE SA that was created and start
fresh with a single pair. But since the responder is also not full
I agree. And whatever we may think of the particular solution, it does present
a problem that can and should be in the problem statement draft.
So how about adding teh following sub-section:
3.7. Different IP addresses for IKE and IPsec
In many implementations there are separate IP addresse
This is why we need multiple vendors to look at this draft.
On Apr 26, 2010, at 2:29 PM, Tero Kivinen wrote:
> Yoav Nir writes:
>> I agree. And whatever we may think of the particular solution, it does
>> present a problem that can and should be in the problem statement draft
Or think of a single IKE gateway that sets up IPsec SAs for multiple IPsec
boxes. Like the key server in MSEC.
On Apr 27, 2010, at 3:27 PM, Yaron Sheffer wrote:
> Hi Jitender,
>
> regarding your point #3: I am not sure that if I trust a gateway to
> connect to, I also trust it to say that all
Can't compete with Martin's "running code", but I have a few comments. Before
that, the draft seems good, and easy to follow. I think developers who have
never heard of the IPsec list should have no problem reading and implementing
this correctly. Having said that, here's two comments.
The intr
Well, this draft is kind of a smorgasbord of issues, so once the issue that
bothers you is in there, you're not that interested any more.
I would like to post another draft with section 3.7 that I posted on the list
on 25-Apr, and unless anyone has another issue that's not addressed, I think we
Well, this draft is kind of a smorgasbord of issues, so once the issue that
bothers you is in there, you're not that interested any more.
I would like to post another draft with section 3.7 that I posted on the list
on 25-Apr, and unless anyone has another issue that's not addressed, I think we
Sorry for the dual post. Some mail client problem.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
I'm fine with the change, and with the reference being either normative or
informative. I prefer informative, though.
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron
Sheffer
Sent: Saturday, May 08, 2010 11:55 PM
To: IPsecme WG
Subject: [
1. I didn't want to make ha-03 dependent on bis, but since bis is now approved,
we may as well do it.
2. OK
3. It should be out of scope, because this is internal to the cluster. We are
not going to require a peer to accept having two SAs with the same SPIs with
the same peer, so it's up to th
How about the following text?
3.8 Allocation of SPIs
SPIs for child and IKE SAs MUST be unique with the same peer. However, in
a cluster, both members may create SAs and assign SPIs to them, so a
collision is possible. We believe that peers should not be required to
accept duplicate
Works for me.
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Stephen Kent
Sent: Thursday, May 27, 2010 5:18 PM
To: Yoav Nir
Cc: IPsecme WG
Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03
At 11:36 AM +0300 5/27/10, Yoav
Hi.
This draft revision includes comments from Jean-Michel Combes and Yaron.
-Original Message-
From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On
Behalf Of internet-dra...@ietf.org
Sent: Tuesday, June 01, 2010 10:15 AM
To: i-d-annou...@ietf.org
Cc: ipsec@iet
Hi Sean.
I have just submitted version -05 which addresses most (but not all) of your
comments. Here's a list of the exceptions (hope I didn't miss any)
#2. I've worded the abstract a little differently. Main difference is adding to
"gaps in existing standards" the words "and their implementati
On Jun 10, 2010, at 6:39 PM, Sean Turner wrote:
> Yoav Nir wrote:
>
>> #13, #15, a few more (no MUST/SHOULD/MAY language). I have two issues with
>> this. The first, is that this document is a problem statement, and intended
>> to be INFORMATIONAL. No gateway is
Done in -06
On Jun 10, 2010, at 7:17 PM, Sean Turner wrote:
> Yoav Nir wrote:
>> On Jun 10, 2010, at 6:39 PM, Sean Turner wrote:
>>
>>> Yoav Nir wrote:
>>>
>>>> #13, #15, a few more (no MUST/SHOULD/MAY language). I have two issues with
>>>
Hi all
No big changes here. Just some nits from the secdir review.
Yoav
On Jun 24, 2010, at 6:00 PM, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions
> Working Group of the IET
, 2010 5:15:22 PM GMT+03:00
To: Yoav Nir mailto:y...@checkpoint.com>>
Subject: New Version Notification for draft-ietf-ipsecme-ipsec-ha-09
A new version of I-D, draft-ietf-ipsecme-ipsec-ha-09.txt has been successfully
submitted by Yoav Nir and posted to the IETF repository.
Filename: d
Sure we are, but I didn't want to start the discussion, because QCD is my
proposal.
Hopefully we've learned something from the history of XAuth vs Hybrid, and we
won't end up with two non-interoperable, proprietary ways of doing this,
neither of which makes it to RFC. I think that failure led
Hi.
Liveness check in IKEv2 is very much like any other INFORMATIONAL exchange.
Here's what the introduction says about this.
An INFORMATIONAL request with no payloads (other than the
empty Encrypted payload required by the syntax) is commonly used as a
check for liveness.
S
Hi all
The Quick Crash Detection protocol is one of the candidates for the failure
detection work item in our charter.
I have implemented in my company's product with a private Notify type and a
VendorID, and up until a few months ago, this has been the only implementation
that I know of.
As
I'd like to point out that section 3 is kind of skeletal at this point, and I
expect that in the final document, each bullet point will be expanded to its
own subsection. I think in the end, section 3 will contain most of the volume
of the document.
We've found that (at least in our opinion) mo
Thanks for the extensive review, Tero.
I haven't had time to read it through yet, but I would like to respond to one
point in this (below)
On Jul 25, 2010, at 4:30 PM, Tero Kivinen wrote:
> The big issue is that the draft does not provide solution to case
> where the IKEv2 SA messages missed a
In today's session there was an disagreement between Yaron and Tero about how
likely it is that messages are missing.
Let's assume our cluster has tunnels with 10,000 peers, and that we do Liveness
Check (DPD) every 20 seconds (StrongSwan default)
Also, let's assume that we synch every 0.1 seco
On Jul 28, 2010, at 9:30 AM, jarrett...@oracle.com wrote:
> A new 00 version of IKEv2 extension for security label has just been
> published:
>
> http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00
>
> Authors welcome comments from IPsec community.
>
> Thanks.
You will get tha
On Aug 4, 2010, at 11:40 PM, Yaron Sheffer wrote:
> In the Maastricht meeting there was just a tiny bit of interest in the
> failure detection idea (reminder: the goal is to ensure that one peer
> discovers that the other IKE peer has restarted, within a short time
> duration, milliseconds inst
On Aug 13, 2010, at 10:07 PM, Scott C Moonen wrote:
> I've looked over the two drafts. My summary impression is that I prefer QCD,
> albeit for subjective reasons. It is less complicated and therefore simpler
> to implement and test. I think I would have a higher degree of confidence in
> plan
Hi all
This might be of interest to the group. Joe is suggesting here (and in the next
messages on the thread) to update RFC 4301.
Begin forwarded message:
> From: Joe Touch
> Date: August 25, 2010 10:55:27 PM GMT+03:00
> To: Thomas Narten
> Cc: "s...@ietf.org"
> Subject: Re: [saag] IPv6 Nod
Hi Scott.
On Sep 3, 2010, at 10:43 PM, Scott C Moonen wrote:
> Looks good. I have one technical question:
>
> - What is the purpose of sending an empty response to the unprotected
> N(INVALID[_IKE]_SPI)&N(QCD_TOKEN)+ message? I'm not sure it provides any real
> value and would really prefer no
On Sep 4, 2010, at 3:01 PM, Kalyani Garigipati (kagarigi) wrote:
>
> 1. If window size is say some five and range expected is 4-8, and if
> peer has got all four requests with values 5,6,7,8 and 4 is lost, then
> there would be no message id that can be used to send the notify
> reset_window.
>
On Sep 5, 2010, at 11:03 AM, Yaron Sheffer wrote:
> In general, the draft is in good shape. But IMO, we have one major
> security issue left: the dependence on SPI values which potentially come
> from a small space, i.e. may be repeated in normal operation, or may be
> coerced into repeating.
On Sep 8, 2010, at 1:50 PM, Tero Kivinen wrote:
> Raj Singh writes:
>>> It's actually worse than that. If message #4 was missed, and 5-8 were
>>> received, then messages 5-8 are stored, but not processed. This has to be
>>> so, because suppose message 7 deletes the SA that was created in message
Hi all.
We're starting discussions of the issues that are open for the failure
detection draft.
Reported by Scott C Moonen:
What is the purpose of sending an empty response to the unprotected
N(INVALID[_IKE]_SPI)&N(QCD_TOKEN)+ message? I'm not sure it provides any real
value and would reall
Reported by Yaron Sheffer:
I would have preferred the token to be resistant to stealing (and duplication),
in which case it can be sent in the *first* AUTH message. If we ensure that the
token maker's SPI is long/random (see below), this might be possible.
The relevant part of the document i
It should be noted that this token protection is available only to EAP users.
endpoints that authenticate with certificates or PSKs are vulnerable to a MITM
enumerating the tokens.
Since issue #191 is up next (tomorrow or thursday), I won't publish a -01
version before #191 is resolved.
On S
OK. there were zero responses to this. Since this seems obvious to me, I will
correct it as Scott suggests, and close the issue with the publication of -01.
On Sep 21, 2010, at 2:58 PM, Yoav Nir wrote:
> Hi all.
>
> We're starting discussions of the issues that are open f
This was actually reported by both Yaron and Tero. I have no problem moving
the QCD token to the first message (in case of EAP), but as Yaron requested, I
will not publish the fixed version before the resolution of #191.
Two more issues soon.
Yoav
On Sep 21, 2010, at 3:06 PM, Yoav Nir wrote
Reported by Yaron Sheffer:
5.1: this method is indeed problemmatic if SPIi/SPIr pairs are repeated with
high probability. If SPI pairs only repeat across reboots (somewhat unlikely),
then an "epoch" (time of last reboot) value can be included to mitigate this
problem. This is still close enough
Reported by Yaron Sheffer:
9.1: this is not really a MUST, let's use some non-RFC 2119 wording.
Yoav Nir: I disagree. We are giving requirements for implementations that
conform to this spec. The requirements vary by the role that the implementation
plays: RA client, RA gateway, Site to
Hi Keith.
After reading your draft, I wish I had done this in RFC 4478. Still, I have
some comments.
What are the considerations for the responder accepting a re-authentication?
Suppose we have an active IKE SA between Alice and Bob. Now Bob gets a new
IKE_SA_INIT request with an N(REAUTH_SA)
nly
> makes sense.
>
> Thanks,
> Yaron
>
> On 10/05/2010 04:33 PM, Yoav Nir wrote:
>> Hi Keith.
>>
>> After reading your draft, I wish I had done this in RFC 4478. Still, I have
>> some comments.
>>
>> What are the considerations fo
f storing
those for the lifetime of the IKE SA. Perhaps we could store the contents of
the previous AUTH payload (or a hash thereof) and sign that.
On Oct 6, 2010, at 11:17 PM, Keith Welter wrote:
>
> Yoav Nir wrote on 10/05/2010 07:33:33 AM:
>
> > Hi Keith.
> >
> > A
I was not suggesting to use SK_d itself.
RFC 5996 says this:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
I suggest replaceing/augmenting it with this:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr | SK_ri
On Oct 7, 2010, at 10:50 PM, Keith Welter wrote:
Yoav Nir mailto:y...@checkpoint.com>> wrote on 10/07/2010
12:26:36 PM:
> I was not suggesting to use SK_d itself.
Sorry, I misread your note. You clearly did not suggest using SK_d itself.
>
> RFC 5996 says this:
>
>
On Oct 7, 2010, at 11:15 PM, Keith Welter wrote:
Keith Welter mailto:welt...@us.ibm.com>> wrote on
10/07/2010 10:26:56 AM:
[...]
> Yoav Nir mailto:y...@checkpoint.com>> wrote on
> 10/07/2010 12:48:17 AM:
> [...]
> > Hi Keith.
> >
> > My responses are b
Hi all
This version resolves issues #189, #190, #191, and #192.
Also the content of section 9.3 has been moved to section 10.4 because, as
Frederic pointed out, it's more a security considerations than operational.
Yoav
On Oct 10, 2010, at 10:30 AM,
wrote:
> A New Internet-Draft is availa
Hi. In -00 this section was labeled 9.3. This issue is very much about
substance, so we would very much like to see discussion of it. Ultimately it
goes to the question of whether and when the methods in 5.1 and 5.2 should be
recommended.
Yaron: 10.4: this entire discussion is probably redund
Yaron: The security considerations are focused on details of the QCD solution,
rather then on the threats we are dealing with. These threats are non-trivial
to describe, since an active MITM attacker can easily cause an IKE SA to be
reset. OTOH, we don't want an active non-MITM attacker to be ab
On Oct 17, 2010, at 2:57 PM, Yaron Sheffer wrote:
> Hi Frederic,
>
> I understand the scenario now and I agree that a solution is needed. But
> I have two issues, one general and one specific:
>
> - Even though there are no interoperability implications, I think we
> should specify the token
less method will likely require more severe warnings in order to
> restrict or constraint its domain of applicability.
>
> regards,
>
> fred
>
> On 17 Oct 2010, at 15:41, Yoav Nir wrote:
>
>>
>> On Oct 17, 2010, at 2:57 PM, Yaron Sheffer wrote:
&
11, 2010, at 8:22 AM, Yoav Nir wrote:
> Yaron: The security considerations are focused on details of the QCD
> solution, rather then on the threats we are dealing with. These threats are
> non-trivial to describe, since an active MITM attacker can easily cause an
> IKE SA to be res
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 issues.
>>
>> Dave Wierbowski
>>
>>
>>
>>
>>
Yaron: 10.3: of course, it is possible that *both* implementations generate
predictable/short SPI values
Hi all.
I think this one was solved together with ticket #191 ("The danger of
predictable SPIs"), but requiring that the token maker randomize IKE SPIs.
Unless somebody (like Yaron) objec
On Oct 20, 2010, at 5:01 PM, Stephen Kent wrote:
> At 4:37 PM +0200 10/20/10, Yoav Nir wrote:
>> Yaron: 10.3: of course, it is possible that *both* implementations
>> generate predictable/short SPI values
>>
>>
>> Hi all.
>>
>> I think this o
701 - 800 of 810 matches
Mail list logo
