I've already asked co-chairs for a slot to present null-auth
in a private e-mail.
Great :)
We should probably add a comment about rekeying. If the responder
becomes the initiator, it might run into issues. Possibly an entity
that did not authenticate the peer should not initiate a rekey.
Hi Yoav,
AUTH_ANON ? Although I think AUTH_NONE is more in line with how we name
things.
I don't agree that it is anonymous. It says that the identity was not
authenticated, it didn't say that no identity was provided.
Section 2.2 says that “As peer identity is meaningless in this case,
Hi Paul,
RFC 5996 states:
Although ESP and AH do not directly include a Diffie-Hellman
exchange, a Diffie-Hellman group MAY be negotiated for the Child SA.
This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA
exchange, providing perfect forward secrecy for the generated
transorms
(for example AES-CBC with implicit IV) instead of
negotiating IV compression separately.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
with just returned cookies and would give the former
higher priority.
I don't see any drawback with this modification, do you?
Regards,
Valery.
Yoav
On Jul 11, 2014, at 9:21 AM, Valery Smyslov sva...@gmail.com wrote:
Hi Yoav,
did you consider the following initial exchange:
Initiator
Hi Yaron,
sorry for late reply - I was on vacation.
I still think that the example is valid. The example describes the remote
opener which
opens the only door. If you want to open different doors using single opener
then you might
run into trouble you described. But this attack can be
No, that is not caused by the unauthenticated protocol, but caused by
the same device to be used with two different doors. Even if the
device would do full authentication and would verify that the door is
in his list of doors which can be opened, attacker could still do the
same thing.
Only way
Hi Hannes,
I agree that the example is a bit artificial and in real life
one would not use IKE/IPsec to control garage door.
At least now. But if IoT becomes ubiquitous then
who knows, probably such setup will be default
off shelf solution...
Regards,
Valery.
P.S. What about mutual
Hi Tero,
This is also question what should we do for the rfc5996bis.
We have two options, we removed the text saying section 2.9.2 was
added in the RFC5996, or we add the section 2.9.2 from the ticket #12,
and add note that saying that this time we really added it...
What does the working
Hi,
if new version of draft-kivinen-ipsecme-ikev2-rfc5996bis is issued,
then it is also possible fix a typo I've come across.
Section 2.8.1, second para:
This form of rekeying may temporarily result in multiple similar SAs
between the same pairs of nodes. When there are two SAs eligible to
as their
native language, clearly let me know that yet and suggest better variants.
Regards,
Valery Smyslov.
A new version of I-D, draft-smyslov-ipsecme-ikev2-null-auth-03.txt
has been successfully submitted by Valery Smyslov and posted to the
IETF repository.
Name: draft-smyslov-ipsecme-ikev2-null
Section 2.23, 4th bullet:
o The recipient of either the NAT_DETECTION_SOURCE_IP or
NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
value to a SHA-1 hash of the SPIs, source or recipient IP address
(respectively), address, and port, and if they don't match, it
Yes.
Obviously, as the author of the document I can see its value,
which is describet in the document itself.
And I think it's better to standardize it with
more people involved, than as individual submission.
Regards,
Valery.
- Original Message -
From: Yaron Sheffer
justify it over MUST.
We can discuss it.
And you are right - some (I dare to say many)
words still need to be added into the Security Considerations
section.
Regards,
Valery.
Thanks
Graham
On 08/09/2014 07:27, Valery Smyslov sva...@gmail.com wrote:
Yes.
Obviously, as the author of the document
Hi Les,
imho, this would be useful for bring-up work i.e. for both developers and
deployers.
However, as folks already pointed out, there are significant security
tradeoffs (and mitigations) that SHOULD/MUST to be explicated (i.e.more
verbiage).
Points to consider:
1) allowing
. The latter at least
prevents passive eavesdropping...
Finally, since Bellovin's attack was mentioned, I want to make sure that no
one is thinking of not using the MAC authentication at the IP packet level,
right?
Absolutely.
Hugo
Regards,
Valery Smyslov.
On Mon, Sep 8, 2014 at 10:54 AM
Hi Rahul, Yaron,
Hi Rahul,
I am not aware of any additional conditions.
Sorry to pop up, but doesn't text from RFC5998 apply only
to EAP-only authentication? Isn't it an additional condition?
I mean, that if you perform EAP authentication, as described
in RFC5996, i.e. when responder does
In Section 3.8 (Authentication Payload) the description
of the 3-octet RESERVED field is absent. I think it is a typo,
as in all other cases, when reserved field is present
in payload (KE, ID, TS, CP), its description is given.
___
IPsec mailing list
In Section 3.13.1 the description of the Selector Length field
doesn't mention that it is unsigned integer (as it is mentioned
for all other such fields).
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
In Section 3.13.1 the description of the Selector Length field
doesn't mention that it is unsigned integer (as it is mentioned
for all other such fields).
What's an unsigned integer? :P
Do we mean octets? :)
Unsigned integer is an interpretation of this two-octets value
(presumably in network
Hi Yaron,
I think that the draft in its original form doesn't exist now (btw, it seemes
to have expired),
as the authors has clearly indicated, that the solution, that was presented
in the draft, is no longer actual, and a new, more simple approach should be
taken.
But it is described in no
1. Section 3.15.1:
o APPLICATION_VERSION - The version or application information of
the IPsec host. This is a string of printable ASCII characters
that is NOT null terminated.
NOT is uppercase. Although it might be an intention to ephasise
the fact, that it is not null
Hi,
I think that the DoS protection is very important problem for IKE
and it needs to be addressed. I have, though, mixed feelings about
the draft in its current form. The idea is very cute, but it has
IMHO a limited usage in protection against DoS attack.
It doesn't protect against DDoS
for adoption
- some grammar errors are fixed
I think that the Security Considerations section is still incomplete.
Please, feel free to suggest the text that should be added there.
Regards,
Valery Smyslov.
- Original Message -
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Cc
, that share
the same credentials. If client established IKE SA with
any of them then the SA could be cloned and transfered
to other nodes of this cluster without reauthentication,
and the traffic from client then could be balanced
among those gateways.
Regards,
Valery Smyslov.
- Original
yaronf.i...@gmail.com
To: Valery Smyslov sva...@gmail.com; Paul Hoffman
paul.hoff...@vpnc.org; IPsecME WG ipsec@ietf.org
Sent: Thursday, November 27, 2014 4:00 PM
Subject: Re: [IPsec] Survey for WG interest in
adoptingdraft-mglt-ipsecme-clone-ike-sa
hat on: RFC 5723 co-author
Hi Valery,
Have you
(this is unlike puzzles in IKE_SA_INIT, where
they should be optional).
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
and it is desirable that it survives reboots
and so on, so it just becomes a timestamp :-)
Regards,
Valery.
I like the two options of the header in the clear.
Many thanks
On 01/12/2014 15:34, Valery Smyslov sva...@gmail.com wrote:
Hi, this is a long message.
First of all I think
Hi Scott,
this is almost identical to what I proposed in my original e-mail,
if you substitute difficulty level with puzzle id.
In more generic way - responder encodes in cookie/puzzle
all the information that could help him quickly
reject invalid/stale/forged puzzles without
wasting resources.
Hi Scott,
this is almost identical to what I proposed in my original e-mail,
if you substitute difficulty level with puzzle id”.
Or call it “generation id”, and increment it whenever you generate a new
secret and/or change the difficulty level.=
That will work. In this case it is better to
you loose the
ability to set a the hardness of the puzzle)
On 03/12/2014 16:01, Yoav Nir ynir.i...@gmail.com wrote:
On Dec 3, 2014, at 5:44 PM, Valery Smyslov sva...@gmail.com wrote:
Hi Scott,
this is almost identical to what I proposed in my original e-mail,
if you substitute difficulty
I get your point, but I think this is more than unfortunate, this is
real ugly. RFC 7383 is primarily about IKE_AUTH, and now, in the case of
those broken networks that limit the MTU, we are reducing the effective
MTU yet again.
Not much, a dozen of bytes.
But I think we're looking at the
it to have
experimental status.
Regards,
Valery Smyslov.
chair hats on
Greetings again. There is a small emerging industry of crypto solutions
that transmit keys using Quantum Key Distribution (QKD), and then use
those keys for classical high-speed encryption. Several such solutions are
using
Hi Yaron,
We are almost in agreement. My understanding is that both the
IKE_SA_INIT and IKE_AUTH puzzles are needed, and each one has a
different goal:
- IKE_SA_INIT puzzle: should counteract the responder's memory cost of
keeping the half-open SA, and its CPU cost in computing DH.
- IKE_AUTH
Are we going into the right direction?
Is it worth to solve the task of making
puzzle difficulties less erratic if the computing power
of clients may differ by the order of magnitude (or even magnitudes)?
Can we make the process more flexible?
For example - the server may indicate two difficulty
Hi Michael,
Can we make the process more flexible?
For example - the server may indicate two difficulty levels in
puzzle
request - the desired one and the acceptable one.
For example, the desired level is 20 bits and the acceptable level
is 16
bits.
You are
I can see two drawbacks with this approach.
First, to make it aligned with algorithm agility, we need to
negotiate not only PRF, but also the encryption algorithm.
And the selection criteria would become more complex.
And second - it significantly increases the size of IKE_SA_INIT
response
Is the following text for the entire section 2.4 OK for you?
(I've borrowed some of your text):
Looks mostly ok.
2.4. Interaction with Peer Authorization Database (PAD)
Section 4.4.3 of [RFC4301] defines the Peer Authorization Database
(PAD), which provides the link between Security
Hi Yoav,
Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2
Hi,
Valery has created this pull request. During the meeting in Honolulu and
subsequent discussion on the list, several people requested that there be a
negotiation of the algorithm used in the puzzle rather than
Hi Yaron, Paul,
* The privileged IKE operations is obviously a bit thin. Initial
Contact may be a good example of an operation that we'd be better
off without. But if we don't have any specific examples, let's remove
this section.
I agree that this section currently is vague. Paul has
That was partially because Valery and I didn't fully agree. Which means
it might not belong in this document. Initial Contact is addressed in
the document already in its own section. The question for example is
about CREATE_CHILD_SA. Which comes back to your point below about
making claims of
Protocol
Authors : Valery Smyslov
Paul Wouters
Filename: draft-ietf-ipsecme-ikev2-null-auth-04.txt
Pages : 13
Date: 2015-02-19
Abstract:
This document specifies the NULL Authentication method and the
ID_NULL Identification
I changed a subject field.
Valery Smyslov writes:
Hi Tero,
On the other hand same section says that ID_NULL SHOULD only be used
with NULL authentication method. In which scenarios do you think
ID_NULL can be used when using normal authentication? I.e. which is
the exception for the SHOULD
Hi Yaron,
The text in RFC7296 specifically does not limit the uses of EAP
identities more than that SHOULD NOT just because we wanted to leave
things open so different implementations can do whatever is suitable
for them.
That's why I think that ID_NULL can be used as IDi
in case of EAP -
Valery Smyslov writes:
I don't see how this can be done without breaking existing
implementations, and therefore I am unhappy with the new sentence in
-03, Another example is EAP authentication when the client identity in
ID payload is not used. A responder that receives a new, unknown ID
type
Hi Yaron,
there is already Section 3.2, which discusses possible
impact of NULL Auth on DOS resistance, and
the ddos/puzzles document is already referenced there.
Do you think more words need to be added to this section?
Regards,
Valery.
- Original Message -
From: Yaron Sheffer
It is fully legal for NAS to sent EAP Identity request and
not use IKE Identity. Then, many modern EAP methods
(like EAP-TLS) have their own means to exchange Identities
within the method, and in this case the initial IKE Identity becomes
almost useless.
And for some EAP libraries getting rid
Some clarifications below.
(seems previous message was lost)
https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth
So since the WGLC came onto us a little early, the document authors
still have some different opinions about some of this. So let me raise
those in the WGLC :)
Hi Tero,
Kathleen Moriarty writes:
Section 3.1
Shouldn't this new requirement only apply to unauthenticated
sessions? Wouldn't requirements for existing authenti
cated sessions remain in terms of audit capabilities and
logging?
This should be
What else could we recommend to do in this situation?
If responder deletes IKE SA in case it receives IKE_AUTH
message that doesn't pass ICV check, then it would give
an attacker an easy way to prevent legitimate initiator
to connect - just monitor the network and once IKE_SA_INIT
from the
Hi Yaron,
Hi Valery,
Sorry if I was inconsistent on this one.
This is a performance optimization, and it's a trade off for the
responder: Do I want to cache keys, thereby saving on CPU but wasting more
memory on potentially useless SAs? So I suggest to make it a MAY, not a
SHOULD.
At
On Feb 26, 2015, at 2:11 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
Greetings again. A few people have expressed interest in having
https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG
item for IPsecME. If you want this as a WG document, and you are willing
to review
Hi,
I support adoption this draft as WG document.
Valery Smyslov.
- Original Message -
From: Paul Hoffman paul.hoff...@vpnc.org
To: IPsecME WG ipsec@ietf.org
Sent: Friday, February 27, 2015 1:11 AM
Subject: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305
Greetings
.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
this clarifies the idea?
Regards,
Valery.
Thanks,
Yaron
On 04/03/2015 02:45, Valery Smyslov wrote:
Hi all,
I've updated my previous pull request.
The source file and changes are available at
https://github.com/ietf-ipsecme/drafts/pull/2
Now it is completely described using puzzles in the IKE_SA_INIT
I'm not sure what the IETF definition is for Update an RFC. I would
say this RFC only adds to 4306. That is, if you do not implement this
document you do not need to know about this update. I would expect an
updated by to be mandatory reading material for an implementor of the
RFC being updated.
or just a genuine IKE_AUTH message from
legitimate initiator which an attacker was able to outpace
with a bogus one) would pass ICV check.
Regards,
Valery.
Thanks,
Yaron
On 04/03/2015 07:47, Valery Smyslov wrote:
Hi Yaron,
Hi Valery,
to make it easier for everyone, I suggest that you submit
Hi,
I also had some concerns on the variance of the times. But then
another thought came to me. Let's look on this issue from the other side.
The responder will use puzzles only when it feels that it is under attack.
It means, that there are a lot of (thouthands, tens of thouthands)
half-open
Hi all,
Yoav added a couple of new issues into the tracker,
so I'd like to initiate the discussion of these issues.
The first issue (#229) is concerned with the inconsistency of the puzzle
solution time with the current definition of the puzzle.
So the question - should we change the puzzle
Hi again,
another issue that is added to the tracker - whether to use
puzzles for protection against nefarious IKE peers after
IKE SA is established.
My opinion - using puzzles after IKE SA is established
is possible, but is not justified. It would significantly
complicate IKE state machine (I
successfully submitted by Valery Smyslov and posted to the
IETF repository.
Name: draft-ietf-ipsecme-ikev2-null-auth
Revision: 06
Title: The NULL Authentication Method in IKEv2 Protocol
Document date: 2015-04-20
Group: ipsecme
Pages: 14
URL:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2
Hi Yoav,
Hi, Valery.
Thanks for the review. See my reply inline.
Technical issues.
1. For the question raised in the draft:
TBD: do we want an extra 32 bits as salt for the nonce like
in GCM, or keep the salt (=SenderID) at zero?
I prefer to follow GCM-like approach, i.e. to take
since IANA will ask this question
anyway.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Hi,
On Mar 30, 2015, at 5:39 PM, Yoav Nir ynir.i...@gmail.com wrote:
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
Hi Yaron,
First, I raised a third concern, which is that allowing the client to
decide on the difficulty of the puzzle it is willing to solve adds
unneeded complexity. Basically the client doesn't have enough information
to make a good decision.
The problem is that the server doesn't have
to the lack
of details you have given, but as you described it must be worked.
Regards,
Valery Smyslov.
Hello,
we would like to implement new vendor specific capabilities under IKEv2.
This capability requires argument passing. These arguments should be
protected (encrypted and signed).
We were
Maintenance and Extensions Working
Group of the IETF.
Title : The NULL Authentication Method in IKEv2 Protocol
Authors : Valery Smyslov
Paul Wouters
Filename: draft-ietf-ipsecme-ikev2-null-auth-07.txt
Pages : 15
Date
.
Hope this long explanation helps.
- 2.5: hand out is an odd phrase here - would be better
to expand on that I think and say more precisely what
should never be done.
I think Paul Wouters, my co-author, will address this
and will expand the text.
Regards,
Valery Smyslov
If your setup is set to that you configure only one Diffie-Hellman for
the IKEv2, which is then used for both IKE SA and Child SAs, then you
would notice this misconfiguration immediately.
My product has a separate configuration for phase 1 Diffie-Hellman group
and phase 2 Diffie-Hellman
we add similar mode to IKEv2?
Regards,
Valery Smyslov.
They don't mention IKEv2. I don't know IKEv2 well enough to know whether there
are
any symmetric PSK authentication schemes, but if not, perhaps there should be.
The point they're making is that the ECC-based authentication methods
to connect to.
Regards,
Valery Smyslov.
- Original Message -
From: Dharmanandana Reddy Pothula
To: s...@elvis.ru ; pwout...@redhat.com
Cc: ipsec@ietf.org
Sent: Tuesday, August 11, 2015 5:44 PM
Subject: [IPSec] The NULL Authentication Method in IKEv2 Protocol -
draft-ietf
Hi Yaron,
that was my idea to use CAPTCHA as a puzzle. My thoughts were the following.
We came to the problem that weak clients cannot solve strong puzzles,
so using puzzles for DDoS protection makes legitimate weak clients
uncapable to establish IKE SA. Then I thought that probably we can use
Hi again,
the idea of memory-intensive puzzle is present in Erik Nygren's draft
TLS Client Puzzles Extension
(http://www.ietf.org/id/draft-nygren-tls-client-puzzles-00.txt).
The idea is to create puzzle in such a way, that the time to solve it
depends rather on available RAM, than on CPU power.
Hi,
I support adopting this document.
Regards,
Valery Smyslov.
Greetings. There was some general interest in having a standard way to
modern elliptic curves for ephemeral key exchange. Please respond in
this thread whether or no you think this document is a good start on
that work
Hi Tommy,
thank you for the answers. See my comments inline.
The idea of using TCP as the fallback from UDP is exactly what the entire draft
is about.
The preconfiguration is not whether to always use TCP, but whether to use TCP
once
UDP fails, and upon which port. Since the entire idea of
termines
peer IP address and protects to some extend from spoofing (I assume ISN
is unpredictable as it should be). Another thing that becomes useless is
sending NAT keepalive messages (but see previous comment).
And IKEv2 extension that becomes useless with T
Hi Tero,
If no
cryptographically protected messages have been received on an IKE SA
or any of its Child SAs recently, the system needs to perform a
liveness check in order to prevent sending messages to a dead peer.
Here - if you don't want to send message to a peer, you don't care
This is exactly what happens when you using NAT-T in normal case too.
I.e. if the responder looses state, it cannot do anything until
initiator reconnects.
What do you mean by state here? SA? It is not so easy for attacker
to force responder loose its SA. If the responder is rebooted than
it
Hi Paul,
The situation described above is quite real. Suppose the client is
downloading a large file
from the server. In this case the server always has data to be sent, while
the client
only responses with ACKs. If the client receives no new data it just waits.
Of course
if it has something
Since the liveliness of a peer is only questionable when no traffic
is exchanged, a viable implementation might begin by monitoring
idleness. Along these lines, a peer's liveliness is only important
when there is outbound traffic to be sent.
That I disagree with. I want to cleanup
Hi Yoav,
First, the problem of IKE having too large packets in certain environments is a
real problem.
We’ve already addressed it with fragmentation, and the TCP encapsulation draft
proposes yet another way.
I don't think that compression is an alternative to TCP encapsulation. TCP
Hi Paul,
If you mean TLS, then as far as I understand the compression-related
attacks
on TLS rely on an ability for an attacker to insert specific data into
the
encrypted (and compressed) stream that contains secret information
(e.g. password). I don't think it's relevant to IKE and it is
It depends on the particular content of the messages. Those payloads that
contain
random (or randomly-looking) data like Nonce, KE, most VIDs are almost
uncompressable.
However the content of SA payload contains so many zeroes that it can be
compressed
of up to 90%. So, if your IKE_SA_INIT's SA
Hi,
I've posted a new draft on using compression in IKEv2.
Comments, thoughts, criticism are very very welcome.
Regards,
Valery Smyslov.
A new version of I-D, draft-smyslov-ipsecme-ikev2-compression-00.txt
has been successfully submitted by Valery Smyslov and posted to the
IETF repository
Hi David,
thank you for the careful review. I hope we'll manage to address your comments
and issue an updated version shortly. Please find more inline.
Regards,
Valery.
- Original Message -
From: Waltermire, David A.
To: IPsec@ietf.org
Sent: Tuesday, December 01, 2015 6:15 AM
Initiators include wildcard
traffic selectors in Request allowing
Responders to narrow them according to its policy.
Hope this helps. Feel free to ask more if you have any concerns.
Regards,
Valery Smyslov.
- Original Message -
From: Michael Christian
To: ipsec@ietf.org
Sent
be
addressed.
Regards,
Valery Smyslov.
- Original Message -
From: Panos Kampanakis (pkampana)
To: Perlner, Ray ; ipsec@ietf.org
Cc: Liu, Yi-Kai ; David McGrew (mcgrew) ; Waltermire, David A. ; Frankel,
Sheila E. ; Scott Fluhrer (sfluhrer) ; Moody, Dustin
Sent: Tuesday, January 12
[ cut everything we agreed ]
> > Depending on the Responder implementation, this can be repeated
> > with
> > the same half-open SA.
> >
> > I don't think this "depends on the implemention". Since any on-path
> > attacker can spoof rubbish, a Responder MUST ignore the
Hi Paul,
An obvious defense, which is described in Section 4.2, is limiting
the number of half-open SAs opened by a single peer. However, since
all that is required is a single packet, an attacker can use multiple
spoofed source IP addresses.
I am not sure why this is
This is the official call for adoption of https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ as an
IPSecME working group (WG) document.
By adopting this draft the WG is agreeing to take this on as an official WG item to continue work on the draft. Please
reply with any comments
Hi Paul,
On the other hand, if we go this way and give the puzzles stuff an
Experimantal status, then probably very few vendors (if any) will implement
it and the real problem of defending against
(D)DoS attacks will remain unaddressed.
I don't think the puzzles implementation adoption will
The concern is not about stand-alone puzzles document. It is about an
Experimental status
of that document versus Standards Track in the current draft. Vendors tend to
ignore Experimental RFCs.
The conventional wisdom is that vendors tend to ignore whatever status the IETF assigns to
Hi Paul,
thank you for the very thorough review (and especially - for the nits).
This is a partial review of draft-ietf-ipsecme-ddos-protection-06
up to Section 6. I hope to complete the rest in the next few days.
I think this document needs another revision before continuing.
(and I would
Hi,
in Buenos-Aires it was expressed a proposal to split
the DDoS protection draft into two. One of them would
describe possible kinds of (D)DoS attacks and would
suggest some counter measures to thwart them without
introducing anything new into the IKEv2 protocol.
The other document (with
rmire, David A. (Fed)" <david.walterm...@nist.gov>
To: "Valery Smyslov" <sva...@gmail.com>; <p...@nohats.ca>
Cc: <ipsec@ietf.org>; "Yoav Nir" <ynir.i...@gmail.com>
Sent: Wednesday, June 22, 2016 8:21 PM
Subject: RE: [IPsec] Review of draft-ietf-ips
Hi Tero,
If I got it right the ability for an attacker to quickly find a hash
collision is based (besides using weak hashes) on presumption that
the cookie is always the very first payload in the message, as
depicted in the Section 2.6 in the RFC 7296. So it is presumed that
the cookie always
Hi Yoav,
What does IPsec community think of it? Should we fix the protocol
to thwart this attack completely? Is the recommendation to move the COOKIE to the end of the message enough to
achive that?
Will this change break many existing implementations?
As far as I can tell, the cookie hash
The initiator cannot validate the cookie - it is an opaque blob for him. Should
he reject
the cookie if its length is more than 64 bytes? Possibly. I don't know.
It's a bit strange to check an opaque object…
It’s an opaque object that the RFC says should be up to 64 bytes.
I know that.
As I've already said I'm not an expert in the IoT world. And I still think
that the compression can
also be used in a "big world". It would allow to keep the IKE_SA_INIT message
size bounded
when more features are added into the protocol. And I don't see it as an
alternative to
TCP
Hi Tommy,
In those environments the IKEv2 is used to negotiate link keys between
two devices. The payloads are already quite compacted, i.e. there will
not be several proposals for ciphers, only one, and all extra payloads
are omitted anyways.
Tero’s comments seem to confirm the idea that
101 - 200 of 811 matches
Mail list logo
