Paul,
It's been over 8 years since this RFC was published, and I have not
looked at it since then. My recollection is that we wrote 5114 because
an IPsec developer approached me and said that he wanted to support
these groups in a product. He said that he wanted test vectors for the
groups,
Yoav,
Is this code available anywhere? If not, it makes it hard to reproduce
their results.
There is a paper on the code design, and I anticipate the code will
become available,
as the work was sponsored by NIST.
It’s too bad they don’t submit this to bench.cr.yp.to so we could have
an
Yoav,
I think it’s risky to base decisions on our attempts to divine future NIST
decisions, but I agree that out best option now is to leave the 64-bit IV (or
nonce) explicit for now and perhaps later add an IKE extension that allows you
to “compress” the IV as long as it’s equal to the
Yoav,
Hi,
There is two questions I would like guidance from the group about.
First is the nonce/IV question: In the current draft, there is a
64-bit IV with guidance not to repeat them (so use a counter or LFSR).
The function itself accepts a 96-bit input nonce, so the nonce is
constructed
As the primary author of 4301, and the creator of the PAD, I believe
this work
does update that section of 4301. I agree with Kathleen that this doc
needs to
say precisely what parts of 4301 are being updated, perhaps using a
before/after
approach.
Steve
On Apr 1, 2015, at 6:57 PM, Kathleen
Paul,
Other authentication methods defined for IKE perform authentication, so
there was
no need to express anything special in the SPD or PAD. NULL is obviously
very
different.
The text you cited from 4727, with the edit you proposed would be a big
improvement.
Steve
Daniel,
Thanks for the explanation.
...
The draft does not specify how matching between IV_i and packet i is
performed.
- 1) you may use the SN as the packet counter. Of course it is
easier if the SN increments for each packet. However SN are not part
of the IV generation.
which SN? the
Daniel,
I read the very brief IV-generation I-D and I didn't see an explanation
of how
to perform IV compression. As someone else already noted on the list,
an IV
is carried with each packet to enable decryption of packets that may
arrive out
of order. Thus it's not enough to have each peer
Paul
On Mar 8, 2014, at 8:08 AM, Black, David david.bl...@emc.com wrote:
The next draft changes AES-128-CBC to AES-CBC, and says:
In the following sections, all AES modes are for 128-bit AES. 192-bit AES
MAY be supported for those modes, but the requirements here are for 128-bit
AES.
What
Paul,
...
It's good to remember the reason that 256-bits keys for AES were specified,
i.e., as a hedge against someone building a quantum computer. So, unless the
data being encrypted is expected to have a lifetime far enough into the future
as to merit protection against that concern, the
Paul,
On Feb 25, 2014, at 8:48 PM, Yaron Sheffer yaronf.i...@gmail.com
wrote:
Hi, this is to start a 2-week working group last call on the revised
Algorithm Implementation Requirements
document, ending March 11. The draft is at:
http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01.
Paul,
On Wed, 26 Feb 2014, Valery Smyslov wrote:
It is for systems that don't implement AH. We should probably say
this explicitly in section 3.
I don't think it is limited for those systems only.
You may implement AH, but yon cannot use it
everywhere, as it is not compatible with NATs.
And
For progress to Internet Standard, we need to verify the status of
implementations
relative to the RFCs. Rather than Going through an exhaustive list of
MUST and
SHOULD compliance, let's start with a simpler list, suggested by Sean.
I request that each implementer complete the following form:
updated versions of RFC 4301, 4302, and 4303 have been posted:
Title : IP Authentication Header (AH)
Author(s) : S. Kent
Filename : draft-kent-ipsecme-ah-rfc4302bis
Pages : 35
Date : Nov. 19, 2013
This
/19/2013 11:06 PM, Stephen Kent wrote:
updated versions of RFC 4301, 4302, and 4303 have been posted:
Thank you Steve for working on these drafts. These drafts are targeted
at republication as Internet Standards. As promised in Vancouver, I
would like to open the question of whether we should
Mike,
Thanks for the responses to my comments, including ones from yesterday's
meeting.
Steve,
Sorry, I wasn't clear on our use of IPsec. We definitely use both the
authentication and encryption capabilities of IPsec. We do the
following when bringing up a new tunnel.
1. Trigger
Manish,
Hi Stephen,
Thanks for your inputs vis-a-vis 4301/2/3. I concur that IPSec is
not just about encryption but don't quite buy into what somebody
spelled out during the meeting as 'IPSec is an access control
mechanism that also provides other security services'; IMO, strict
access
Manish,
Steve,
To answer your question, the SPD entries are not already there, they
are created as the result of a message exchange between the two
spokes; it's the spokes that choose the policy, not the hub. If the
SPDs were already there, every IPSec node in the network would need to
know
Mike,
A couple of your comments caught my attention, as an author of 4301, 02,
and 03. I admit to not having read the DMVPN proposal, so my comments
are based only on your message, which argues why DMVPN is the preferred
solution.
IPsec encryption layer. In this layer ISAKMP/IKEv2/IPsec is
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. They are not used interchangeably.
The same seems to apply to use of terminology re data origin
authentication, integrity, etc.
On 1/4/13 3:23 PM, Andrey Jivsov wrote:
...
Point compression is more beneficial for storage security for reasons
of performance and storage efficiency. For storage efficiency side:
when there are multiple recipients per message, each associated with
one ECDH-related field, it's possible
Dan,
My recollection is that the agreement at the SECDIR meeting was that a
waring of the form not for use with IKEv1 was part pf the deal. I
still believe this is a very questionable way to accommodate the IEEE's
unwillingness to maintain their own registry, and their slow doc rev
cycle
I provided a number of comments in response to the -00 version back in
April.
According to the diff tool in data tacker, the -01 version is identical,
except that the author list and dates have changed.
So it's not clear that comments really are appreciated.;-)
Steve
At 10:11 PM + 4/9/12, Xiangyang zhang wrote:
Steve
Even though TCP or IP does not envision it, the ordered processing
is very common now. In an intermediary node, IP reassembly and TCP
reorder must be done some time. In flow-based technology (for
example, stateful firewall), without IP
At 4:50 PM + 4/6/12, Xiangyang zhang wrote:
Stephen,
You understand this method very well. The disadvantage is the
possible severity of out of order delivery. Even with single SA, it
can also cause the out of order problem. As for re-order, just like
TCP reorder or IP reassembly, it
At 9:49 AM -0500 4/9/12, paul_kon...@dell.com wrote:
At 4:50 PM + 4/6/12, Xiangyang zhang wrote:
Stephen,
You understand this method very well. The disadvantage is the possible
severity of out of order delivery. Even with single SA, it can also
cause the out of order problem. As for
At 4:44 AM + 4/6/12, Xiangyang zhang wrote:
Steve,
Your understanding is partially right. Only that anti-replay window
could possibly be bigger if two paths go along the different routes.
If two paths go along the same route, it is no difference from the
traditional single SA. But the
At 1:12 AM + 4/3/12, Xiangyang zhang wrote:
A new version of I-D, draft-zhang-ipsecme-multi-path-ipsec-00.txt
has been successfully submitted by Xiangyang Zhang and posted to the
IETF repository.
Filename:draft-zhang-ipsecme-multi-path-ipsec
Revision:00
Title:Multiple Path
At 4:39 PM +0800 1/29/12, zong.zaif...@zte.com.cn wrote:
Hi Stephen, Tricci:
Sorry that I didn't respond this email on time due to the chinese
spring festival. I would like to thank Stephen first for reviewing
the draft and giving me your suggestions.
no problem. Happy New Year.
From
At 2:40 PM +0800 1/20/12, zong.zaif...@zte.com.cn wrote:
Hi Folks:
There is a new draft available that some of you may be interested
in looking at.
The draft is available via the following link:
http://www.ietf.org/id/draft-zong-ipsecme-ikev2-cpext4femto-00.txt
Please send your comments to
At 4:54 AM +0530 11/23/11, Jack Kohn wrote:
As per RFC 4301 implementing AH is a MAY and ESP a MUST. Given that
most of what is achieved by AH can be easily achieved by ESP-NULL, is
there a possibility that AH may get deprecated in the future. Should
new protocols or mechanisms be defined in
At 1:56 AM -0500 11/15/11, Steven Bellovin wrote:
On Nov 13, 2011, at 4:30 PM, Vilhelm Jutvik wrote:
De...
The notion of discarding AH entirely has been discussed for many years.
I've long been in favor of it, though I can't find a copy of anything old I
had posted in my mail archives at the
In most contexts, there is no real benefit to using two SAs (AH +
ESP) as you describe. I agree that, in almost every case, just using
ESP will suffice. Using ESP in tunnel mode is certainly good enough,
and less expensive than 2 SAs.
Steve
___
At 8:15 PM -0600 10/19/11, Kevin Gross wrote:
We don't need decrypt and encrypt to take the same amount of time.
We need encrypt+decrypt from master to slave to take the same time
as encrypt+decrypt from slave to master.
That further reduces the likely variance that is algorithm or mode
At 11:24 AM +0530 8/29/11, Naveen B N (nbn) wrote:
Hi Scott,
Even with the Pre-shared secret, the protocol can't keep up the
property of perfect Forward secrecy.
I have assumed the both the server and client use pre-shared secret,
same below methods applies to Certificate based
At 11:05 PM +0200 2/11/11, Yaron Sheffer wrote:
Hi Steve,
[Cross-posted to ipsecme]
I have always wondered about these sequence numbers, and the concept
of anti-replay in IPsec.
- IPsec is architecturally a plug-in replacement for IP. And IP
allows for arbitrary packet deletion,
At 10:40 AM +0530 11/23/10, Anil Maguluri wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary=_000_903D13EA90218E43BA0881BC8B569C7D0F8B8FB7B1BLRINMSMBX01b_
Hi All,
Please clarify me the below query.
è When AH Header Length becomes zero (in which scenario)?
è
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 one was solved together with ticket #191 (The danger
of predictable SPIs), but requiring that the token maker randomize
Yoav,
I did not mean to suggest that the SPD UI has to be a low level
interface that makes it difficult for users to achieve their secruity
goals. On the other hand, I would be surprised if any vendor's UI
really accepted English (or another human communication language).
So, despite the
At 10:00 AM +0530 2/19/10, 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 guidelines, such that IPSEC/IKE
At 12:14 PM +0200 2/10/10, Alper Yegin wrote:
Dan,
Hi Alper,
In that case there is no standard way for the AAA server to inform
the
IKEv2 responder of this policy that it needs to enforce. So that
sounds
unworkable.
I guess it can be specified.
The IKEv2 responder already has
At 11:41 AM +0200 2/8/10, Alper Yegin wrote:
Yoav,
When the IKEv2 responder offloads the Authentication, Authorization, and
Accounting (AAA) responsibilities to a centralized AAA server, it is no
longer in the business of figuring out who the peer is, if the peer is
really who it claims it is,
At 3:02 PM +0530 1/11/10, Bhatia, Manav (Manav) wrote:
Dan,
You trust the end nodes to negotiate WESP and encapsulate their ESP
packets in WESP but you don't trust the content they put into those
packets. Is that the trust model you're operating on?
No.
We trust the end nodes to put
At 5:13 PM + 1/7/10, Brian Swander wrote:
In this scenario, the sum of functionality is
greater than the parts - end hosts and
intermediaries working together can achieve
better overall security than either working in
isolation and in complete distrust of the other.
It'll be up to the
At 11:14 AM -0700 1/5/10, Grewal, Ken wrote:
Yes to both, based on arguments already discussed numerous times in
the WG via presentations, 12 iterations of the draft and multiple WG
last calls + AD reviews!
The main motivation for extending the ICV was to counter some of the
issues
Gabriel,
...
One may argue whether that consistency check is best served by
extending the ICV to include the
WESP header fields (per the current WG consensus as expressed in the
existing draft), or whether
that is best done by the end nodes checking the fields explicitly.
My reply to Ken
At 10:10 PM + 1/5/10, Brian Swander wrote:
I'll resend my message from earlier today that gives a concrete
scenario for why the WESP encryption bit is in charter.
To satisfy the existing charter item, we need a deployable solution,
which entails working with legacy systems that don't
At 9:45 AM +0530 1/6/10, Venkatesh Sriram wrote:
Would it help if WESP is renamed to something else? Since we're
discussing the fundamental principles of the protocol, i see no reason
why we cant change the name, if that helps. I think its the Wrapped
in the WESP thats causing most heart
At 5:19 PM +0200 1/6/10, Yaron Sheffer wrote:
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
At 9:34 PM +0200 1/6/10, Yaron Sheffer wrote:
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
At 12:48 PM -0700 1/6/10, Grewal, Ken wrote:
Steve,
The either-or on using an ICV or explicitly checking the WESP header
on the recipient was based on the assumption that the threat does
not come from the sender and only from some other malicious entity
after the packet has been sent.
This
Folks,
The flurry of messages that have been exchanged today and yesterday
have often struck me as incorporating rather vague arguments. I find
myself having to do a lot of work to fill in the blanks for not
well-articulated comments, construct detailed analyses, and postulate
rationales for
At 7:55 PM + 1/6/10, Brian Swander wrote:
I trust my clarification (to Yaron) addressed these questions. Let
me know if there are any outstanding.
I understood the first two lines about lots of legacy systems, only a
few of which need to perform encryption. The next two lines were too
At 12:27 AM +0200 1/5/10, Yaron Sheffer wrote:
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
At 6:17 AM +0530 12/29/09, Jack Kohn wrote:
Are you suggesting that ESP ICV should not cover the WESP fields?
I think, and my memory could be failing me, that this was discussed in
the WG before this got added to the draft.
Jack
I am suggesting that WESP should be cleanly layered, in one of
At 8:20 AM +0530 12/18/09, Raj Singh wrote:
...
IKE is Internet Key Exchange protocol NOT IPsec Key Exchange protocol.
IKEv2 is not just a mean of exchanging keys but its a full package.
This package provides mutual authentication, keys and readiness to
secure data as needed.
The main
Yaron,
I hate to admit it, but I lost track of the details of WESP as it
progressed through WG discussions and briefings at IETF meetings.
When I read the I-D in detail, I was very surprised to see that it
was no longer a neatly-layered wrapper, as originally proposed. The
fact that it now
At 6:24 PM + 12/7/09, Brian Swander wrote:
0 - option data does not change en-route. This option is
included in the WESP ICV computation.
We'll be using this flag, so this option will always be integrity protected.
integrity protected for checking by the end system, but not
verifiable
At 7:50 PM + 12/7/09, Brian Swander wrote:
In case it wasn't clear for the earlier WESP discussions, we need
this to also work with simple transport mode: i.e. not just
transport mode inside tunnels terminating at various infrastructure,
and not just in tunnel mode.
The transport nesting
Paul,
From your comments it seems as though an IP option would be
preferable, as it is not IP-sec-specific, and it an be protected if
needed, in the IPSec context, e.g., via tunneling.
Steve
___
IPsec mailing list
IPsec@ietf.org
Folks,
I think there is merit to pursing both the EAP-based and the
SPSK-based password authentication proposals as WG items. My
rationale is:
- EAP-based methods are well-suited to client-server
interactions and to enterprise environments that already use
RADIUS/DIAMATER. Unfortunately,
Jack,
Thanks for describing the additional selection criteria that must be
employed to avoid the problem I cited.
Given this more complete description of the selection criteria, I am
not convinced that that is a significant benefit for using WESP in
this context.
- Whether using WESP or
I am opposed to pursing this work at this time. The ongoing
discussion on the list suggests that the arguments put forth for WESP
use in the OSPFv3 context, the first concrete proposal outside of the
middlebox inspection context that motivated WESP, have not been
validated. The presentation
At 12:11 PM +0100 11/25/09, Daniel Migault wrote:
Hi Manav,
I agree that for an already negotiated SA, the SPD lookup detects IP
source address spoofing. So in that case ESP detects the address
spoofing during the SPD check whereas AH would detect it while
checking the signature check.
At 11:09 PM +0530 11/21/09, Jack Kohn wrote:
Steve,
4301 contains We have explicit directions on how to use multiple SAs when
the peers know that they want to send traffic with different QoS parameters.
This appears to be an instance where the middle boxes are to examining
traffic, and
At 6:48 AM +0530 11/13/09, Bhatia, Manav (Manav) wrote:
Daniel,
AH is a security feature we need to keep for header authentication
Am really not sure about the value that AH adds even in case of
header authentication.
So what fields does AH protect:
Version, Payload length, Next Header,
At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote:
Steve,
I would have no problem deprecating AH in the context of the IPsec
architecture document, if others agree. It is less efficient than
ESP-NULL. However, other WGs have cited AH as the IPsec protocol of
choice for
At 11:29 PM +0800 10/14/09, Zhen Cao wrote:
O...
IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other OS. With
most of them, the latest versions support IPv6 for IKE and IPsec.
I guess we do not need tunnel model for IPv6 ipsec?
what makes you say that? unnelT mode is still
Marcus,
Thanks for the additional background. I am not an expert on 3GPP. Do
you know if there an IETF liaison to the 3GPP? If so, the right
approach is to have that individual coordinate an action like this
between the SDOs, i.e., when SDO-A wants SDO-B to modify/extend a
protocol to
At 4:06 PM -0400 9/11/09, Marcus Wong wrote:
Steve, you are mostly right, but this I-D only deals with the integrity data
exchange using the notify payload. Thanks.
Marcus
Thanks for the clarification. That still raises the question of why
we ought to duplicate this NEA functionality in
At 11:46 AM -0400 9/11/09, Marcus Wong wrote:
Hi Everyone,
I'm new to the working group. I've uploaded a draft on the use of notify
payload for integrity data exchanges in IKEv2 for your comments and review.
All comments are highly appreciated. Thanks everyone.
A new version of I-D,
At 2:57 PM +1000 7/27/09, Greg Daley wrote:
...
Your reference to 4301 regarding the use of multiple parallel SAs solving
the example is helpful. I will remove the example for clarity.
As Tero noted, RFC 4301 provides a discussion of how an
implementation can, on a local basis, deal with
At 9:34 PM +0530 5/12/09, Murthy N Srinivas-B22237 wrote:
Is there a new draft/rfc posted with the change incorporated?
-ns murthy
DES is deprecated, so I would not expect a revised RFC on that. AES
is strongly preferred over 3DES, so there is little incentive to rev
that doc, although it
At 2:18 PM +0300 4/29/09, Tero Kivinen wrote:
...
In most case I would not expect Bob to create the old SA that way at
all, as it would require it to combine two SPD rules together when
accepting such entry. As the SPD entries are ordered list that would
mean it was combining two entries which
Prabhat,
With regard to your first observation, I'll note that your argument
appears to be based on particular implementation choices. We don't
generally consider changes to standards based on such choices, unless
a lot of vendors indicate that there are no viable implementation
options
75 matches
Mail list logo
