Yaron,
It is important for you to state what problem you're trying to solve.
That problem is, simply, password-only authentication. To bring up the
motivation for adding EAP to IKEv2 is quite irrelevant since EAP in IKEv2
today involves server-side authentication using a certificate.
You w
Hi Yaron,
On Mon, November 30, 2009 10:47 pm, Yaron Sheffer wrote:
> Hello Dan,
>
> [WG co-chair hat off]
>
> EAP-only authentication is a small IKE extension that does not change the
> existing IKE architecture; neither does it change many of the extant
> implementations. Given the right EAP m
Hi Matthew,
Please take a look at both proposals. There is no proposal to simply
offer guidelines. Both of them are "new solutions" and modify the IKE
exchange. One uses NOTIFY messages to indicate the new exchange and the
other uses the critical bit to indicate the new exchange. I would be
i
Hi Dan,
> And in that case EAP encapsulation of the underlying key exchange would
> be completely pointless and extraneous, would double the number of
> messages required to complete the exchange, and would increase the amount
> of security-critical code.
EAP authentication was not primarily incl
Dan Harkins writes:
> Groups 1 and 2 were defined in RFC 2409 and repeating them in a
> subsequent RFC does not change that.
RFC2409 has been obsoleted, so I do not want to refer to that, as
people will then go to the RFC2409 and notice that it has been
obsoleted by RFC4306, and will go to there
Hi Martin,
On Tue, December 1, 2009 1:27 am, Martin Willi wrote:
> Hi Dan,
>
>> And in that case EAP encapsulation of the underlying key exchange would
>> be completely pointless and extraneous, would double the number of
>> messages required to complete the exchange, and would increase the
>>
Hi Dan,
I'm sorry, but you are misstating the difference between the proposals. One is
adding a notification and eliminating one existing (certificate) check; the
other is adding an IKE mode, and changing the protocol state machine in the
process.
Regardless of all the other pros and cons, the
Yaron Sheffer writes:
> EAP was added to IKEv2 to provide "legacy" (a.k.a. password)
> authentication. In the past it did not do it very well, but this is
> changing. We should improve the use of EAP in IKEv2, rather than
> replacing it by a homebrew solution.
EAP can really only be used in the c
One of the (or main?) motivations of this proposal is to turn IKEv2 into
"EAP-based network access authentication protocol". RFC 5191 is designed
for that purpose, and I'm not sure if we need to twist a protocol for the
same purpose.
> -Original Message-
> From: ipsec-boun...@ietf.org [
Matthew Cini Sarreo writes:
> From a developer point of view, I share the same opinion as Yaron about this
> issue. Instead of creating new solutions, I personally think that it would
> be better to offer guidlines on how to implement current solutions (i.e EAP)
> and provide documents targeting im
Hi Tero,
I think you are too quick to dismiss the option of using EAP-only for
site-to-site and transport deployments, where the EAP state machine is embedded
into the IKE endpoint. For people who already have client-side EAP, this is not
adding a lot. It's not as efficient as tailor-made passw
There were several motivations listed for childless IKE SAs.
- remote access, where you create an IKE SA when the user wants to connect,
and only create child SAs in response to traffic
- authentication only over a physically secure network (not necessarily EAP,
but I think this is the use case
The section 1.2 says that if we get INTERNAL_ADDRESS_FAILURE then the
IKE SA stays up, but the child SA is not created. It does not say
anything what should happen on the initiator if it actually did
require address by policy.
I think we have two options:
1) Tear down the IKE SA (by sending DELET
During the last 3GPP SA3 meeting, such requirement about HNB has also
been approved as well.
thanks
-Hui
2009/12/1 Yoav Nir :
> There were several motivations listed for childless IKE SAs.
> - remote access, where you create an IKE SA when the user wants to connect,
> and only create child SAs
The section 2.9 has text which says:
--
2.9. Traffic Selector Negotiation
... Since the two endpoints may be configured by different
people, the incompatibility may persist for an extended period even
in the absence of e
Paul Hoffman writes:
> At 9:46 AM +0200 10/21/09, Yoav Nir wrote:
> > A few lines above this section it already says "If the responder's
> > policy allows it to accept the first selector of TSi and TSr, then
> > the responder MUST narrow the traffic selectors to a subset that
> > includes the initi
Yaron Sheffer writes:
> I'm sorry, but you are misstating the difference between the
> proposals. One is adding a notification and eliminating one existing
> (certificate) check; the other is adding an IKE mode, and changing
> the protocol state machine in the process.
Not true.
Both are adding n
On Tue, Dec 01, 2009 at 03:24:18PM +0200, Tero Kivinen wrote:
> The section 1.2 says that if we get INTERNAL_ADDRESS_FAILURE then the
> IKE SA stays up, but the child SA is not created. It does not say
> anything what should happen on the initiator if it actually did
> require address by policy.
I
At 12:03 PM +0200 12/1/09, Tero Kivinen wrote:
>Dan Harkins writes:
>> Groups 1 and 2 were defined in RFC 2409 and repeating them in a
>> subsequent RFC does not change that.
>
>RFC2409 has been obsoleted, so I do not want to refer to that, as
>people will then go to the RFC2409 and notice that i
Hi Yaron,
EAP is a client/server protocol. If either side can initiate the
exchange (necessary for site-to-site and transport) then each side
will be required to implement BOTH the EAP client and EAP server
state machines. "[P]eople who already have client-side EAP" will
need to add server-si
Paul Hoffman wrote:
> - Add [IKEV2IANA] to the Normative References; it will point to the
> URL of the IANA registry.
I don't like the idea of splitting the normative content of RFC 4306
to two different places.
An informative reference would be very useful (and probably some of
the tables may
Hi Dan,
I will not argue about the implementation complexity. Such arguments are
useless in general, and I certainly cannot argue with your first-hand
experience.
But EAP does solve, perfectly, the client-to-server use case. The password can
be offloaded to AAA or not, depending on security an
Hi Martin,
If you (or anybody else) support EAP-only auth (or any of the other 6 drafts),
please commit to review it assuming it becomes a WG document. *This* was the
main point of this discussion thread: we cannot make progress without committed
editors and reviewers.
Thanks, and apologies fo
Hi Team,
According to me, High Availability needs protocol level support from IKEv2
due to windowing and sequence numbers in IPsec.
This will enhance performance and avoid proprietary versions of different
vendors. Here we can discuss various problem and solution of IPsec and HA,
which surely need
Hi Team,
According to me, we need to support this draft as WG item as it appears to
enhance the failure detection time.
Currently, there are many scenarios, in which we detect and delete stale SA
only by max. re-transmits.
I would like to review this draft.
Regards,
Raj
2009/11/29 Yaron Sheffer
Hello all,
I myself do not like the current method for detecting that a peer has lost
state (generally this means waiting for a number of retransmits, whom each
of which has a time out). In my opinion this would be a good item for the WG
to work on and would enhance IKEv2. I would like to review t
26 matches
Mail list logo
