On Oct 7, 2010, at 11:15 PM, Keith Welter wrote:
Keith Welter mailto:welt...@us.ibm.com>> wrote on
10/07/2010 10:26:56 AM:
[...]
> Yoav Nir mailto:y...@checkpoint.com>> wrote on
> 10/07/2010 12:48:17 AM:
> [...]
> > Hi Keith.
> >
> > My responses are below, but first I would like to know if yo
On Oct 7, 2010, at 10:50 PM, Keith Welter wrote:
Yoav Nir mailto:y...@checkpoint.com>> wrote on 10/07/2010
12:26:36 PM:
> I was not suggesting to use SK_d itself.
Sorry, I misread your note. You clearly did not suggest using SK_d itself.
>
> RFC 5996 says this:
>
>{SK_d | SK_ai | SK_ar |
Keith Welter wrote on 10/07/2010 10:26:56 AM:
[...]
> Yoav Nir wrote on 10/07/2010 12:48:17 AM:
> [...]
> > Hi Keith.
> >
> > My responses are below, but first I would like to know if you have
> > considered a different solution - having an IKE_AUTH exchange in the
> > middle of the IKE SA lif
Yoav Nir wrote on 10/07/2010 12:26:36 PM:
> I was not suggesting to use SK_d itself.
Sorry, I misread your note. You clearly did not suggest using SK_d
itself.
>
> RFC 5996 says this:
>
>{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
>= prf+ (SKEYSEED, Ni |
I was not suggesting to use SK_d itself.
RFC 5996 says this:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
I suggest replaceing/augmenting it with this:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr | SK_ri
Hi Yoav,
I made a couple posts before reading this. Sorry about that.
Yoav Nir wrote on 10/07/2010 12:48:17 AM:
[...]
> Hi Keith.
>
> My responses are below, but first I would like to know if you have
> considered a different solution - having an IKE_AUTH exchange in the
> middle of the IKE SA
A colleague pointed-out that including the old SK_d itself in the
REAUTH_SA notification is a bad idea. A better approach would be to
incorporate it into the new AUTH payload.
> RFC 4301 section 4.4.3.4 "How the PAD is Used" says:
>Child SAs are created based on the exchange of traffic sel
Answering my own question...
> > What are the considerations for the responder accepting a
re-authentication?
> >
> > Suppose we have an active IKE SA between Alice and Bob. Now Bob
> > gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs
> > for the old IKE SA. When should Bob
Hi Keith.
My responses are below, but first I would like to know if you have considered a
different solution - having an IKE_AUTH exchange in the middle of the IKE SA
lifetime. Suppose the IKE SA has been around for a couple of hours, and has
been used for creating some child SAs, why not keep
Hi Yaron,
Adding an empty REAUTH_SA notification in the original IKE_AUTH exchange
is a nice way to determine in advance of a reauth if both peers support
the protocol. It might be sufficient to only include it in the response
as is done with the CHILDLESS_IKE_SUPPORTED notification in
draft-
Hi Keith,
I think you can exchange the REAUTH notification in the *original*
IKE_AUTH exchange (when you authenticate for the first time), probably
with an empty notification data. This would let both peers know that
they both support the protocol. And then during reauth, you can still
have t
Yoav Nir wrote on 10/05/2010 07:33:33 AM:
> Hi Keith.
>
> After reading your draft, I wish I had done this in RFC 4478.
That's encouraging. Thanks.
> Still, I have some comments.
>
> What are the considerations for the responder accepting a
re-authentication?
>
> Suppose we have an active
On Oct 5, 2010, at 7:48 PM, Yaron Sheffer wrote:
> Hi Yoav,
>
> you are discussing two separate issues related to identity: the "alleged
> identity" (the name presented as IDi and/or authenticated by the
> IKE_AUTH exchange) and the ability to correlate the two SAs using some
> secret informa
Hi Yoav,
you are discussing two separate issues related to identity: the "alleged
identity" (the name presented as IDi and/or authenticated by the
IKE_AUTH exchange) and the ability to correlate the two SAs using some
secret information.
I think we should be flexible about the alleged identi
Hi Keith.
After reading your draft, I wish I had done this in RFC 4478. Still, I have
some comments.
What are the considerations for the responder accepting a re-authentication?
Suppose we have an active IKE SA between Alice and Bob. Now Bob gets a new
IKE_SA_INIT request with an N(REAUTH_SA)
Hi Keith,
> subject "[IPsec] Reauthentication extension for IKEv2"
> certainly rough consensus was not reached.
There was not much demand for such as an extension at this time. To sum
it up, the two main arguments against such an extension were:
1. The current procedure is good enough / it's not
Tero Kivinen wrote on 09/30/2010 02:13:40 AM:
> Keith Welter writes:
> > 1. reiterate how reauthentication works in RFC 5996 (quote third
paragraph
> > of section 2.8.3)
>
> I have not yet read your draft, but how dows it relate to the RFC
> 4478? Isn't that already defining things that would h
Keith Welter writes:
> 1. reiterate how reauthentication works in RFC 5996 (quote third paragraph
> of section 2.8.3)
I have not yet read your draft, but how dows it relate to the RFC
4478? Isn't that already defining things that would help a lot, for
example I think that can be used to force one
Yaron Sheffer wrote on 09/29/2010 01:58:10 PM:
> Hi Keith,
>
> I am responding only to your last point, on error cases.
>
> If the new SA setup fails, the old IKE SA MUST NOT be affected in any
> way. Otherwise (if we recommend to drop the old SA), we would have an
> unauthenticated attacker D
Hi Keith,
I am responding only to your last point, on error cases.
If the new SA setup fails, the old IKE SA MUST NOT be affected in any
way. Otherwise (if we recommend to drop the old SA), we would have an
unauthenticated attacker DOS'ing an entire IKE SA and its Child SAs.
Yes, I think aut
Hi Yaron,
Thanks for your preliminary comments. In-line responses below.
Keith Welter
IBM z/OS Communications Server Developer
Yaron Sheffer wrote on 09/28/2010 02:40:46 PM:
> Hi Keith,
>
> thanks for exploring this important issue. Here are a few preliminary
> comments:
>
> - The intro is
Hi Keith,
thanks for exploring this important issue. Here are a few preliminary
comments:
- The intro is short on motivation: what *exactly* happens today, and
why it is a problem that needs to be solved: bandwidth? CPU? Memory?
Complexity?
- There's a long treatment of simultaneous reauth
After writing this draft (
http://www.ietf.org/id/draft-welter-ipsecme-ikev2-reauth-00.txt), I
re-discovered an old thread about the same issue. The post that started
the thread was from Martin Willi on Tue, 16 Sep 2008 with subject "[IPsec]
Reauthentication extension for IKEv2" (
http://www.ie
A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has been
successfully submitted by Keith Welter and posted to the IETF repository.
Filename: draft-welter-ipsecme-ikev2-reauth
Revision: 00
Title:Reauthentication Extension f
24 matches
Mail list logo
