Hi, Alper
Not all of them.
-Hui
2009/12/2 Alper Yegin :
> Hi Hui,
>
> Are all 4 motivations below part of 3gpp discussion?
>
> Alper
>
>
>> -Original Message-
>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
>> Of Hui Deng
>> Sent: Tuesday, December 01, 2009 3:28
Hi Hui,
I think it'd also be very useful if you indicate which ones are.
Thanks.
Alper
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Hui Deng
> Sent: Thursday, December 03, 2009 4:47 PM
> To: Alper Yegin
> Cc: ipsec@ietf.org; Yoav Ni
(Apologies if this is a dupe. I sent it out yesterday, but it still hasn't
shown up on the list yet, so I figured I better resend from a different
account).
Here is another WESP extension that we are interested in.
Packet Contents Option
0 1 2
If there are no further comments, this issue will be closed.
Issue #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3?
==> As a result of Tero's comments, added #2 below and revised #3. #1 and #4
remain unchanged from the previous email sent to the list.
Proposed changes to R
If there are no further comments, this issue will be closed.
Issue #112: Truncation of SHA-1 ICVs
==> Several people commented that the non-truncated versions of HMAC-SHA-1 and
HMAC-MD5 are only intended to be used for Fibre Channel traffic. Thus, IKEv2
can only negotiate these versions for tha
Issue #114: Expired drafts, especially BEET
==> Tero and Yaron suggested wording changes. The 2nd paragraph below contains
those changes.
#114: Expired drafts, especially BEET
Proposed changes to Roadmap doc:
Add text to the introductory section for IKEv1, Section 4.1.1:
Additional text (revi
If there are no further comments, this issue will be closed.
Issue #115: Camellia req levels for IKEv2
==> Tero commented that this was fine with him.
Proposed changes to Roadmap doc:
1) Change IKEv2 requirement level for Camellia-CBC from undefined (no RFC)
to optional
2) Add
This is an initial attempt to resolve Issue #113. We would appreciate
comments/suggestions/alternate approaches.
#113: Use of AES-XCBC in IKE
Currently, the Req levels are SHOULD for IKEv1 (based on RFC4109) and optional
for IKEv2. The Req levels for AES-XCBC-PRF are SHOULD (based on RFC4109)
I would like to review further versions of this draft and be interested in
contributing text.
regards,
Min
On Sun, 29 Nov 2009 19:18:59 +0200, Yaron Sheffer wrote:
This draft proposes an extensibility framework for WESP, as well as several
specific extensions.
Proposed starting point:
I am interested in discussing on this topic further.
I would like to review this draft.
regards,
Min
Sun, 29 Nov 2009 19:18:59 +0200, Yaron Sheffer wrote:
This work item proposes an IKEv2 extension to allow an IKE peer to quickly
and securely detect that its opposite peer has lost state. Thi
I will be interested in reviewing this and might also contribute some
text to the draft.
Jack
On Sun, Nov 29, 2009 at 10:50 PM, Yaron Sheffer wrote:
> This draft proposes an extensibility framework for WESP, as well as several
> specific extensions.
>
>
>
> Proposed starting point:
> http://tool
Yaron Sheffer wrote:
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 S
Yaron Sheffer wrote:
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.
I am not interested in any further extensions to WESP.
In particular,
Yaron Sheffer wrote:
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 clust
Yaron Sheffer wrote:
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
Yaron Sheffer wrote:
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:
I believe
Dan Harkins wrote:
2. solves the specific problem it is aimed at poorly-- doubling of
the number of messages, requiring writing and testing of new
state EAP state machines that are, otherwise, unnecessary; and,
Does it double, or does it really just "n+1", which is doubling
Tero Kivinen wrote:
SPSK can be used when there is requirement for host to host (or site
to site) connection, where either end can initiate traffic and
exchanges and where entities still want to use passwords instead of
public keys to authenticate. Shared keys could be used there, but in
most set
Yaron Sheffer wrote:
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
To clarify: we don't want "an EAP method". We would like to slightly extend
IKEv2 to use existing, and future, EAP methods that fit the bill.
Thanks,
Yaron
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Michael Richardson
> Sent
20 matches
Mail list logo
