Hi Dave,
I don't have any strong feelings about MUST NOT vs. SHOULD NOT, but I wonder if
it would help to clarify the reasoning behind it.
For these algorithms, RFC6071 (IPsec/IKE Roadmap) says:
- Reuse of the IV with the same key compromises the data's security; thus,
AES-GCM should not be us
sidering the tremendous amount of hard work that went into the
RFCs.
Regards,
Sheila
From: Stephen Kent [k...@bbn.com]
Sent: Tuesday, March 12, 2013 1:05 PM
To: ipsec@ietf.org; Frankel, Sheila E.
Subject: Re: [IPsec] Updated ESP/AH algorithm I-D
Sheil
rch 12, 2013 11:09 AM
To: ipsec@ietf.org; Frankel, Sheila E.
Subject: Re: [IPsec] Updated ESP/AH algorithm I-D
Sheila,
I did a quick check of 4301, and it uses the term "confidentiality"
consistently when referring to the service, and uses "encryption" to
refer to the mechanism
Hi David and Wajdi,
Your updated ESP/AH algorithm doc looks great, and is very much needed. I just
have one comment. You speak of the 2 services provided by ESP and AH as
confidentiality and "data origin authentication." As I'm sure you know,
authentication is used in different ways by differen
We just submitted an updated version (-10) of the IPsec/IKE Roadmap doc.
In accordance with Sean's recommendations, we addressed Tim Polk's comments as
follows:
> Comment:
> (1) I understand that this is a forklift upgrade for RFC 2411, so the usual
> "Changes Since ..." section would not be he
An updated IPsec/IKE roadmap (version 09) was submitted in response to the
Gen-ART review.
Here are the changes that were made in response to that review:
> I found one open issue - Sections 5.4.1 and 5.4.2 mis-state the applicability
> of combined mode algorithms to IPsec-v2. All of the other
We just submitted version -08 of the Roadmap doc. As Yaron requested, we
changed the reference in section 5.2.4 and eliminated Appendix A. We left RFC
4359 in the doc, since some (but not all) of the msec RFCs were deleted, but we
felt this one should remain. (It's not one of the RFCs that Pasi
Announcing the USGv6 Testing Meeting at NIST.
To be held on Thursday May 20th 2010 in the AML Conference Room,
Building 215 Room C103, from 9am till 5pm.
Following publication of the USG Profile NIST has established a testing
program to determine products' compliance to USGv6 capabilities. Ther
Here are the RFCs that Pasi suggested adding/removing from the roadmap doc. If
anyone has any strong opinions either pro or con, now's the time to speak up.
Sheila and Suresh
several groups of RFCs that Pasi wants us t
Here are our responses to Pasi's AD comments on the roadmap doc. We have
indicated which changes we plan to make, and which ones we would prefer to
handle somewhat differently.
We would appreciate hearing from the list, both those who agree and those who
don't. We will send a separate email lis
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)
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
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 #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
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
IPsec. So I guess I should change the new text to
only allow IKEv2 to use both versions for its own SAs, but not for IPsec SAs.
Sheila
From: Scott C Moonen [mailto:smoo...@us.ibm.com]
Sent: Tuesday, October 27, 2009 12:17 PM
To: Frankel, Sheila E.
Cc: ipsec@ietf.org
.@vpnc.org; Frankel, Sheila E.
Subject: [ipsecme] #115: Camellia req levels for IKEv2
#115: Camellia req levels for IKEv2
---+
Reporter: paul.hoff...@… | Owner: sheila.fran...@…
Typ
Internet Drafts are not specified in
this roadmap.
From: ipsecme issue tracker [t...@tools.ietf.org]
Sent: Friday, October 16, 2009 8:29 PM
To: paul.hoff...@vpnc.org; Frankel, Sheila E.
Subject: [ipsecme] #114: Expired drafts, especially BEET
#114: Expired
, Sheila E.
Subject: [ipsecme] #112: Truncation of SHA-1 ICVs
#112: Truncation of SHA-1 ICVs
---+
Reporter: paul.hoff...@… | Owner: sheila.fran...@…
Type: defect | Status: new
; Frankel, Sheila E.
Subject: [ipsecme] #111: Can IKEv1 negotiate combined algorithms to be used by
IPsec-v3?
#111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3?
---+
Reporter: paul.hoff
sloppiness enough to
account for both NULL encryption and AES-CTR being specified for IKEv2 - and
noone from the WG noticing either?
Sheila
From: Paul Hoffman [paul.hoff...@vpnc.org]
Sent: Wednesday, October 21, 2009 3:50 PM
To: Frankel, Sheila E.; Te
etf.org
Cc: Frankel, Sheila E.; pasi.ero...@nokia.com
Subject: RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document
I was reading the USGv6 profile, and it complained that RFC4307 and
RFC4835 do not agree on status of NULL encryption. RFC4307 says MAY,
and RFC4835 says MUST.
As far as
Following the publication of the USGv6 Profile version 1.0, NIST and its
testing partners have been developing the USGv6 Testing Program. Various
aspects of the program have been offered for review to various
constituencies over the past 18 months or so. The program will begin
operations on No
We just submitted an updated (version 04) roadmap draft. We would like to thank
everyone who took the time to read the doc and submit comments.
This email contains comments that led to changes in the doc, along with the
changed text. It also mentions suggested changes with which we disagreed. So
24 matches
Mail list logo
