Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2

ron > -Original Message- > From: pgut001 [mailto:pgut...@wintermute02.cs.auckland.ac.nz] On Behalf > Of Peter Gutmann > Sent: Friday, March 05, 2010 2:07 > To: pgut...@cs.auckland.ac.nz; u...@ll.mit.edu; Yaron Sheffer > Cc: c...@irtf.org; ipsec@ietf.org > Subject: RE: [IPs

Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2

Can someone please explain the joke to me? Nelson was asked about TLS-PSK (RFC 4279) and he replied that it can easily be abused. TLS-PSK (similarly to IKE-PSK) is vulnerable to dictionary attacks if used with a short secret (a.k.a. "password"), at least in the presence of an active attacker. So

Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2

Hi Dan, I consider reuse of DH groups a minor issue at best. But yes, it's a valid criterion. Thanks, Yaron > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Wednesday, March 03, 2010 0:26 > To: Yaron Sheffer > Cc: Dan Harkins; P

Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2

on. It is noted up front that this work item poses a higher > > chance of failing to be completed than other WG work items; this is > > balanced by the very high expected value of the extension if it is > > standardized and deployed. > > == > > > > As the

Re: [IPsec] [Cfrg] Beginning discussion on secure password-only authentication for IKEv2

Whether or not the EKE patent is broad enough, if you search the IPR repository for RFC 2945 (SRP), you will find out that more than one company is happy to post an IPR warning related to SRP. This of course does not prove anything - they're just saying that their patents "might apply". BTW, I a

Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-08.txt - final WG review period

Hi, This version of IKEv2-bis resolves dozens of issues received from many WG members during (and after) the Last Call. I would like to thank everybody who helped to improve this document, and the authors for the great effort that went into -08. We are *not* planning a second WGLC. Instead, I

[IPsec] WG documents

Hi, You may have noticed that two new WG docs were published today. Both of them are individual submissions which were named as "starting points" in the newly approved WG charter. We have updated the document status wiki page (http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/DocumentStatus). Pa

Re: [IPsec] yet more ikev2bis issues

There's a typo in the proposed text to #147: "is further" -> "if further". Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of Tero Kivinen > Sent: Thursday, February 11, 2010 14:27 > To: Yoav Nir > Cc: 'ipsec' > Subject

[IPsec] Issue #154, was RE: Yet another closing session - issues #153-#157

Hi Tero, Going back to the original issue: there is no interoperable way to send "generic dummy packets". So it's OK if we mention dummy ESP packets, but anything else would be implementation specific. Even pings. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.or

[IPsec] Issue #161, was: RE: More Issues for IKEv2bis

Issue #161 should have referred to 2.21.2, not to 2.21. But reading the text again, I am happy with the way it's worded in -07. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of Yoav Nir > Sent: Monday, February 08, 2

Re: [IPsec] IKEv2bis Issue #157

I find Tero's figure easier to understand, more "illustrative". This is obviously very subjective. Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of a...@tr-sys.de > Sent: Wednesday, February 03, 2010 20:12 > To: ipsec@ietf.o

Re: [IPsec] Fwd: Issue : Regarding EAP identity

m>> Cc: Yaron Sheffer mailto:yar...@checkpoint.com>> At 9:09 AM +0530 2/3/10, Raj Singh wrote: Hi Paul, In ikev2bis07 - ikev2-bis-07 section 2.16, last paragraph --- When the initiator authentication uses EAP, it is possible that the contents

[IPsec] Issue #148, was: RE: Five more issues to close in IKEv2bis

Here's a concrete rewording proposal. Old: The term "cookies" originates with Karn and Simpson [PHOTURIS] in Photuris, an early proposal for key management with IPsec, and it has persisted. The Internet Security Association and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header inc

Re: [IPsec] Fwd: Internal WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)

1. It's a race condition. 2. It ain't over till it's over - published by the RFC Editor. > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of Yoav Nir > Sent: Tuesday, January 26, 2010 23:28 > To: Paul Hoffman; IPsecme WG > Subject: Re: [IPsec]

Re: [IPsec] IKEv2-bis comments: 2.17 and onwards

Hi Tero, please see below. Thanks, Yaron > -Original Message- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Monday, January 25, 2010 13:31 > To: Yaron Sheffer > Cc: IPsecme WG > Subject: [IPsec] IKEv2-bis comments: 2.17 and onwards > > Yaron Sheffe

Re: [IPsec] IKEv2-bis, conformance requirements

Hi Tero, Valery, As much as it would be fun to discuss the conformance criteria (personally I agree that they are too stringent, and would become even less relevant if we add things like password-based auth), it is out of scope of the IKEv2-bis discussion. Referring to the guidelines we agreed

Re: [IPsec] Issue #157: Illustrate the SA payload with a diagram

e; however, other proposals in the same SA payload are processed as usual." Thanks, Yaron > -Original Message- > From: Paul Hoffman [mailto:paul.hoff...@vpnc.org] > Sent: Saturday, January 23, 2010 21:19 > To: Yaron Sheffer; ipsec@ietf.org > Subject: RE: [IPsec]

[IPsec] IKEv2-bis comments: 2.17 and onwards

1.7: This also lead to -> This also led to 2.21.: EAP Failure cases are missing altogether. Also, the first paragraph says that if an auth failure occurs at the responder, AUTHENTICATION_FAILED is included in the protected response (to IKE_AUTH), while the last paragraph says it's a separate In

Re: [IPsec] Issue #157: Illustrate the SA payload with a diagram

Hi Paul, Please see below. > -Original Message- > From: Paul Hoffman [mailto:paul.hoff...@vpnc.org] > Sent: Saturday, January 23, 2010 3:28 > To: Yaron Sheffer; ipsec@ietf.org > Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a > diagram > > A

[IPsec] Issue #157: Illustrate the SA payload with a diagram

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 | ---- |

Re: [IPsec] IKEv2-bis, comments up to 2.16

> -Original Message- > From: Valery Smyslov [mailto:sva...@gmail.com] > Sent: Friday, January 22, 2010 20:55 > To: Yaron Sheffer; Tero Kivinen > Cc: ipsec@ietf.org > Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16 > > Hi Yaron, > > > Hi Tero, > &g

Re: [IPsec] IKEv2-bis, comments up to 2.16

osite (that payload order doesn't matter)? Thanks, Yaron > -Original Message- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Wednesday, January 20, 2010 18:29 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: RE: [IPsec] IKEv2-bis, comments up to 2.1

Re: [IPsec] Issue #152: EAP failure and acknowledgement

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

[IPsec] Issue #154: Sending dummy messages during rekey

Sec. 2.8: "An initiator MAY send a dummy message on a newly created SA if it has no messages queued in order to assure the responder that the initiator is ready to receive messages." A dummy (higher level protocol) message on an IPsec SA is way out of scope. Whether such messages even exist is

Re: [IPsec] Issue #150: What happens if the peer receives TEMPORARY_FAILURE and does not understand it

See my earlier mail exchange with Tero. That section is descriptive, not prescriptive, and we should describe why the (new) message sequence works fine with older clients, even though they obviously don't support the new notification. What you say below may be sufficient: there's stale state lyi

Re: [IPsec] IKEv2-bis, comments up to 2.16

Hi Paul, Thanks for rejecting my issues so quickly :-) Please see some comments below. I have deleted issues where I accept the rejection. Yaron > -Original Message- > > = > 1.4.1: the last paragraph springs a surprise by defining the behavior > of IKE SA deletion while dis

Re: [IPsec] Issue #152: EAP failure and acknowledgement

In fact, the whole message sequence of EAP Failure is not described anywhere, and is at best hinted in 2.21.2, which in general assumes the basic 2-message IKE_AUTH exchange. Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of

Re: [IPsec] new traffic visibility draft

So we finally have a draft that attempts to resolve all the issues that were raised by the IESG. As you know, some important changes were made, so if you care about the draft (basically every regular participant expressed an opinion during the poll...), please reread it now. Thanks, Yar

Re: [IPsec] IKEv2-bis, comments up to 2.16

Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Wednesday, January 20, 2010 18:29 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: RE: [IPsec] IKEv2-bis, comments up to 2.16 > > Yaron Sheffer writes: [snip] > > > > > 2.8.2: we should add a sentence on what happens if

Re: [IPsec] IKEv2-bis, comments up to 2.16

Hi Tero, thanks for your response. Some comments below. Yaron > -Original Message- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Wednesday, January 20, 2010 14:22 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: [IPsec] IKEv2-bis, comments up t

[IPsec] IKEv2-bis discussion - please jump in!

Hi everyone, Right before this document is sent to our AD, this is the last chance for us as a group to put the finishing touches on it. I'd like to urge you all to read the comments that were sent to the list in the last few days, add your own comments if necessary, and actively participate in

[IPsec] IKEv2-bis, comments up to 2.16

Abstract: "It replaces" -> "This specification replaces" (otherwise "it" could refer to the protocol itself). 1: Remove bracketed first paragraph of the Introduction. 1: "IKE message flow" -> "An IKE message flow". 1.1.3: "IPsec- protected" - remove space. 1.2: in the table, add "IKE header (n

Re: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)

To clarify, I was only referring to the notifications defined in -bis. Not in any other documents. -Original Message- From: Valery Smyslov [mailto:sva...@gmail.com] Sent: Tuesday, January 19, 2010 9:35 To: Yaron Sheffer; Paul Hoffman; Tero Kivinen; ipsec@ietf.org Subject: Re: [IPsec

[IPsec] Notify types, was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)

I agree with Tero, regardless of the discussion we had on where to put the tables etc., the document needs to be internally consistent. So we should add the new notify types that we're defining in *this* document to the notify types table. Luckily there aren't many. Thanks, Yaron -

Re: [IPsec] Traffic visibility - proposed way forward

From: Yaron Sheffer Sent: Tuesday, January 12, 2010 13:37 To: 'ipsec@ietf.org' Subject: Traffic visibility - proposed way forward Hi, Thanks to the IESG feedback, we have had a long and enlightening discussion on the list. But we have not reached consensus on either of the two question

[IPsec] Traffic visibility - proposed way forward

Hi, Thanks to the IESG feedback, we have had a long and enlightening discussion on the list. But we have not reached consensus on either of the two questions. As a result, Paul and I are proposing the following resolution, which appears to be acceptable both to the draft's editors and to the IE

Re: [IPsec] Traffic visibility - consensus call

at depend on this distinction. And this is why a smooth migration is so important. Over time you get a larger and larger portion of the network to play by the rules. Thanks, Yaron -Original Message- From: Dan Harkins [mailto:dhark...@lounge.org] Sent: Thursday, January 07, 2

Re: [IPsec] Traffic visibility - consensus call

Hi Dan, There are multiple good ways to indicate ESP-null traffic. We just chose one option. But (assuming you strongly dislike heuristics, which some of us do) the big question is how to indicate *encrypted* ESP. Deprecating ESP-null is a non-starter: it is "changing ESP" just like changing t

Re: [IPsec] Traffic visibility - consensus call

Hi Joy, Sorry but this is not the case. Quoting your text below: "The use of the "USE_WESP_MODE" for IKEv2 as indicated in the draft guarantees that WESP-capable nodes only use ESP for encryption and WESP for ESP-NULL." This is incorrect: proponents of the encryption flag would have the WESP-c

Re: [IPsec] Traffic visibility - consensus call

heuristics, even if only on the "slow path". An intermediary shouldn't rely on the entire network being tuned to its needs. Thanks, Yaron From: Brian Swander [mailto:bria...@microsoft.com] Sent: Wednesday, January 06, 2010 21:34 To: Yaron Sheffer; Stephen Kent Cc: ips

Re: [IPsec] Traffic visibility - consensus call

Hi Steve, [No hat.] Thanks for the analysis, I hope this'll help the discussion to converge. You are taking an either-or approach in the last paragraph below. But assuming that WESP is useful (bear with me...), there will be a gradual deployment within any given network. I agree that heuristic

Re: [IPsec] Traffic visibility - consensus call

Hi Brian, [no hat on] I think your reasoning about the different scenarios actually demonstrates that "super-WESP" is useful. But I have to strongly disagree with the statement below. Yes we should support all possible permutations. There's no reason why WESP should suddenly cause traffic that

Re: [IPsec] Traffic visibility - consensus call

is opinion is not shared by everyone. Thanks, Yaron -Original Message- From: Stephen Kent [mailto:k...@bbn.com] Sent: Wednesday, January 06, 2010 19:10 To: Yaron Sheffer Cc: Scott C Moonen; Venkatesh Sriram; ipsec@ietf.org; ipsec-boun...@ietf.org Subject: Re: [IPsec] Traffic

Re: [IPsec] Traffic visibility - consensus call

I would like to reframe the migration discussion. Manav, Scott and everyone else, please correct me if I got it wrong. Suppose we have a middlebox that can do useful things if it knows that the flow is unencrypted, and only basic things if it is encrypted. A load balancer is a good example. We

[IPsec] Traffic visibility - consensus call

Hi, We have had a few "discusses" during the IESG review of the WESP draft. To help resolve them, we would like to reopen the following two questions to WG discussion. Well reasoned answers are certainly appreciated. But plain "yes" or "no" would also be useful in judging the group's consensus.

Re: [IPsec] Clarifying what happens with INITIAL_CONTACT

Looks good to me. Yaron -Original Message- From: Paul Hoffman [mailto:paul.hoff...@vpnc.org] Sent: Monday, December 28, 2009 17:36 To: Yaron Sheffer; IPsecme WG Subject: Re: [IPsec] Clarifying what happens with INITIAL_CONTACT At 5:28 PM +0200 12/28/09, Yaron Sheffer wrote

Re: [IPsec] Clarifying what happens with INITIAL_CONTACT

Hi Paul, You are adding two MUSTs, which we SHOULD NOT do unless we have very good reasons, such as interop problems, security issues, or major functionality problems (like memory leaks). I'm not sure any of these apply, so I suggest that you change the wording to be non-normative. Thanks,

Re: [IPsec] WESP encryption support

Paul and I agree that a discussion is needed, and we will open this discussion in a week's time, when most of the WG members are back from vacation. In the meantime, Happy Holidays! Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf O

Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)

ice. > > > > Thanks, > > --David > > > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA  01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_da...@emc.com    Mobi

Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)

Hi Tero, I support your position (and disagree with Yoav). We had better fix this problem now by allocating a few more numbers, than live forever with an ambiguous interpretation to the numbers that everybody's using. Thanks, Yaron -Original Message- From: ipsec-boun...@ietf.or

Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility

Hi Tero, Allowing the more generic, encrypted WESP (as per the current I-D) would let vendors experiment with different extensions. Yes, they might play with some extensions that you and I find ugly or even insecure. But crippling WESP today would mean that any such extensions are (1) limited t

Re: [IPsec] Issue #130: Do we need to bump the minor version number?

Or else, we could remove the sentence "For example, it might indicate the ability to process a newly defined notification message." I thinking bumping the minor version number would be extremely risky. We know that everybody can ignore unknown notifications. We don't know that everybody can deal

Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility

Hi Dan I agree with you regarding some of the proposals that have been floating around re: exposing bits and pieces of encrypted data. I disagree though that WESP should not be used for encrypted data: - It is simpler for implementations and architecturally cleaner for WESP to support both fla

Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes?

This seems to prove that no such "minimal implementations" exist, because they would leak memory like crazy. So we could simply say that INFORMATIONAL messages containing DELETE payloads are an exception to the "you may return an empty INFORMATIONAL" rule. Thanks, Yaron ___

Re: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to continue.

t; From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Friday, December 11, 2009 15:45 > To: Yaron Sheffer > Cc: Paul Hoffman; ipsec@ietf.org > Subject: Re: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to > continue. > > Yaron Sheffer writes: > > I think Tero'

Re: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to continue.

I think Tero's text is somewhat speculative in assuming that this error case only results from exhaustion of the address pool - I'm sure there can be other reasons. Otherwise the text is OK. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@

[IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!)

This is to begin a 4 week working group last call for draft-ietf-ipsecme-ikev2bis-06. The target status for this document is Proposed Standard, obsoleting RFC 4306 and RFC 4718. Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups to this message. This is a large document

Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2

Hi Nico, If I understand you correctly, EAP crypto binding is what IKEv2 provides by default, by including the EAP MSK into the IKE AUTH payload (RFC 4306, sec. 2.16 and 2.15). I believe what Dan is discussing is enabling secure transmission of ID parameters over the EAP channel (sorry...), whi

Re: [IPsec] Proposed work item: Labelled IPsec

Please remember that it is up to the WG to define the work item. The I-D is just a possible starting point, so if there's strong interest in this area, you may wish to reach consensus on a charter item - and to convince the rest of us that enough people are interested. Thanks, Yaron >

Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2

> Michael Richardson > Sent: Friday, December 04, 2009 5:20 > To: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2 > > Yaron Sheffer wrote: > > This draft proposes an IKEv2 extension to allow mutual EAP-based > authentication in IKE

Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO

nted venue would also help in soliciting more and better reviews. Thanks, Yaron > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Wednesday, December 02, 2009 21:12 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Propos

Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO

ld be irresponsible to ONLY have this limited level of review. Regarding the process at the EMU side of the house, I share your frustration... Thanks, Yaron > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Tuesday, December 01, 2009 10:19 > To: Y

Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2

for picking on you :-) Yaron > -Original Message- > From: Martin Willi [mailto:mar...@strongswan.org] > Sent: Tuesday, December 01, 2009 11:27 > To: Dan Harkins > Cc: Yaron Sheffer; ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: EAP-only authenticatio

Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO

dings, and will (eventually) be solved. Adding a few protected fields to any particular EAP method is not a big deal. Thanks, Yaron > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Tuesday, December 01, 2009 22:04 > To: Yaron Sheffer > Cc

Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO

-made password authentication in IKE, but OTOH it is much more generic. Thanks, Yaron > -Original Message- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Tuesday, December 01, 2009 15:04 > To: Yaron Sheffer > Cc: Dan Harkins; Matthew Cini Sarreo; ipsec@ietf.org &

Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO

cons, the proposals are clearly not comparable as far as changing the protocol. Thanks, Yaron > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Tuesday, December 01, 2009 11:01 > To: Matthew Cini Sarreo > Cc: Yaron Sheffer; ipsec@ietf.org &

Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2

e.org] > Sent: Tuesday, December 01, 2009 1:06 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2 > > > Hello, > > I do not believe this is a reasonable activity to spend WG time on. > The reason i

Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO

Sent: Tuesday, December 01, 2009 1:35 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > (SPSK) > > > Hello, > > As can be inferred by my previous posting on EAP-only authentication, > I favor th

[IPsec] Proposed work item: IKE/IPsec high availability and load sharing

This work item will define the problem statement and requirements for a solution that allows interoperable HA/LS device groups. Mixed-vendor clusters are specifically out of scope; but single-vendor clusters should be fully interoperable with other vendors' devices or clusters. The main challeng

[IPsec] Proposed work item: WESP extensibility

This draft proposes an extensibility framework for WESP, as well as several specific extensions. Proposed starting point: http://tools.ietf.org/id/draft-montenegro-ipsecme-wesp-extensions-00.txt. Please reply to the list: - If this proposal is accepted as a WG work item, are you committi

[IPsec] Proposed work item: Labelled IPsec

This work item proposes to extend IKEv2 (and IKEv1) so as to allow IPsec to be used in environments that require Mandatory Access Control. It is envisioned that this will be used by modern high-security operating systems, that go beyond the currently supported Multilevel Security (MLS). Propose

[IPsec] Proposed work item: Failure detection in IKEv2

This work item proposes an IKEv2 extension to allow an IKE peer to quickly and securely detect that its opposite peer has lost state. This is claimed to be quicker than the current method, which is based on time outs. Proposed starting point: http://tools.ietf.org/id/draft-nir-ike-qcd-05.txt or

[IPsec] Proposed work item: IKEv2 password authentication (SPSK)

This draft proposes a particular method for mutual authentication of IKEv2 peers using a short, low quality shared secret (a.k.a. "password"). The proposal is to embed this method in the IKE exchange, rather than use EAP. Proposed starting point: http://tools.ietf.org/id/draft-harkins-ipsecme-s

[IPsec] Proposed work item: Childless IKE SA

This draft proposes an IKEv2 extension to allow the setup of an IKE SA with no Child SA, a situation which is currently disallowed by the protocol. Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-childless-01.txt.   Please reply to the list:   - If this proposal is accepted a

[IPsec] Proposed work item: EAP-only authentication in IKEv2

This draft proposes an IKEv2 extension to allow mutual EAP-based authentication in IKEv2, eliminating the need for one of the peers to present a certificate. This applies to a small number of key-generating EAP methods that allow mutual authentication.   Proposed starting point: http://tools.ie

[IPsec] IPsecME rechartering

Hi everyone, The following 7 messages request your input regarding the activities that were proposed for the next phase of the IPsecME WG. This is an open process, and we specifically request that you reply to the mailing list, rather than privately, whether you are committing to review/author

Re: [IPsec] Ensuring future extensibility for WESP

Hi Min, Thanks for your (correct) comment. Yaron > -Original Message- > From: Min Huang [mailto:huang...@huaweisymantec.com] > Sent: Saturday, November 28, 2009 11:57 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Ensuring future extensibility

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

Given the amount of interest on the list, I prefer the "do nothing" approach. Just add this text somewhere (maybe multiple times): This table is (these tables are) only current as of the publication date of RFC 4306. Other values may have been added since, or will be added after the pub

Re: [IPsec] #117: Hash and URL interop

Can you live with: Implementations MUST support HTTP. The behavior of other URL methods is not currently specified, so such methods SHOULD NOT be used in the absence of a Standards Track document defining them. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [

Re: [IPsec] #118: Reference for PKCS #7

, they may still be adding useful stuff. This is just speculation on my part, not actual knowledge. Thanks, Yaron > -Original Message- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Wednesday, November 25, 2009 14:01 > To: Yaron Sheffer > Cc: IPsecme WG > S

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

Hi Paul, I have marked below with an asterisk those that I think should stay in the document, because they are important to understanding/implementing the protocol. Overall, I'm not sure this exercise is worth our time. In particular if we strip tables of their values, there's a high risk of in

Re: [IPsec] #119: Which certificate types can be mixed in one exchange?

. David also asked whether we'd want to fold RFC 4806 (OCSP extensions to IKEv2) into -bis. My personal opinion is No, despite the fact that it is a Proposed Standard. From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent: F

Re: [IPsec] #116: The AUTH payload signature

signatures. From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent: Friday, October 30, 2009 1:18 To: IPsecme WG Subject: [IPsec] #116: The AUTH payload signature The definition of the payload (sec. 3.8) should mention explicitly that the payload hash al

Re: [IPsec] #120: CA indication with cert req - allowed types

Please also see Tero's follow-up here: http://www.ietf.org/mail-archive/web/ipsec/current/msg04990.html From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent: Friday, October 30, 2009 1:15 To: IPsecme WG Subject: [

Re: [IPsec] #118: Reference for PKCS #7

Russ later pointed out that there are multiple RFCs defining PKCS #7. Inputs on current implementations are welcome. From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent: Friday, October 30, 2009 1:18 To: IPsecme WG

Re: [IPsec] #117: Hash and URL interop

Resending. There may be value in other URL methods, just maybe, but OTOH they would confuse developers and add security issues. From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent: Friday, October 30, 2009 1:18 To

[IPsec] Cert-related IKEv2-bis issues

Hi, Since we didn't have time to discuss these issues in Hiroshima, I'd like to reopen them on the list. Please refer to my slides: http://www.ietf.org/proceedings/09nov/slides/ipsecme-7.pdf for a summary of the issues. This message will be followed by a restatement of each of the 5 issues.

[IPsec] Closing #22 (was: RE: Closing #25)

And this is exactly the table that I claim needs to remain in the spec. A list of errors - even if partial! - is essential to understanding a protocol. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Paul Hoffman >

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

Hi Paul, Please add to Issue #123 a list of the affected tables. For example, I wouldn't imagine the list of notification types moving away, even though it's already been extended by IANA. Similarly for the stuff in Sec. 3.6, which is strongly related to descriptive text. Thanks, Yaron

[IPsec] Ensuring future extensibility for WESP

Hi, The recent draft on extending WESP which was presented in Hiroshima, explains why the current WESP is *not* extensible, and we would need a new version number if we are to add any extensions in the future. It is up to the WG to decide whether or not we want to adopt the draft, given that m

[IPsec] IPsecME WG report

IPsecME met this morning. We have one RFC (IKEv2 Redirect) recently published, and a couple more in the RFC Editor queue. The other "small" drafts are coming along as well. The group is making progress on IKEv2-bis, and we had a presentation on one thorny protocol issue that was resolved by a d

Re: [IPsec] Updating IPsec algorithm requirements

r not there are any good alternatives to it. Thanks, Yaron > -Original Message- > From: David McGrew [mailto:mcg...@cisco.com] > Sent: Saturday, November 07, 2009 1:22 > To: Paul Hoffman; Yaron Sheffer; ipsec@ietf.org > Subject: Updating IPsec algorithm requirements

[IPsec] #120: CA indication with cert req - allowed types

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 certificate requests of type 7,

[IPsec] #119: Which certificate types can be mixed in one exchange?

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) Can have one or more CRLs and/or OCSP content (RFC 4806) added to any of the

[IPsec] #118: Reference for PKCS #7

PKCS#7 should reference RFC 2315. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] #117: Hash and URL interop

To improve interoperability, allow only the "http" URL method. The current text (end of sec. 3.6) implies that any method is allowed, although HTTP MUST be supported. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] #116: The AUTH payload signature

The definition of the payload (sec. 3.8) should mention explicitly that the payload hash algorithm is unrelated to the one used in the certificate, or the algorithm used to sign the IKE Encrypted Payload. Moreover, the words "by default" are confusing and should be deleted.

[IPsec] Certificate-related issues

Hi, I will follow this message with 5 IKEv2-bis issues, all related to certificate handling in IKEv2. Note that these are not "PKIX issues", none of them has anything to do with the internal format of the certificate. They all have to do with the somewhat underspecified interaction of IKEv2 wit

[IPsec] FW: [btns] RFC 5660 on IPsec Channels: Connection Latching

-Original Message- From: btns-boun...@ietf.org [mailto:btns-boun...@ietf.org] On Behalf Of rfc-edi...@rfc-editor.org Sent: Wednesday, October 28, 2009 21:19 To: ietf-annou...@ietf.org; rfc-d...@rfc-editor.org Cc: b...@ietf.org; rfc-edi...@rfc-editor.org Subject: [btns] RFC 5660 on IPsec

Re: [IPsec] [ipsecme] #114: Expired drafts, especially BEET

I'm OK with this text. Typo: know => known in the last sentence. Yaron > -Original Message- > From: Frankel, Sheila E. [mailto:sheila.fran...@nist.gov] > Sent: Tuesday, October 27, 2009 17:46 > To: ipsec@ietf.org > Cc: Paul Hoffman; Yaron Sheffer; sures

<    1   2   3   4   5   6   7   >