headers
Alejandro Perez Mendez | 2 May 2006 11:52
Picon
Favicon

Original initiator and responder after an IKE_SA rekeying in Repeated authentication scenario in IKEv2

Hi! We need some clarifications about how to know who are the original
initiator and responder in Repeated Authentication scenario in IKEv2.

The Repeated Authentication document assumes that only the original
responder can send the AUTH_LIFETIME notification, but after an IKE_SA
rekeying, the original responder can change (see IKEv2 clarifications
document section 5.9). After that, the original responder may be
different to the "original authentication responder" (the peer that acts
as responder in the IKE_AUTH exchange).

In this case, who is the "original responder" in order to send
AUTH_LIFETIME notifications?

--

-- 
Alejandro Perez Mendez
Pedro J. Fernandez Ruiz

University of Murcia
OpenIKEv2 http://openikev2.sf.net
Permalink | Reply | 2 comments |
headers
Yoav Nir | 2 May 2006 12:00
Picon
Favicon

Re: Original initiator and responder after an IKE_SA rekeying in Repeated authentication scenario in IKEv2

By "original responder" I mean the party that was Responder in the 
original Initial and AUTH exchanges, so perhaps "original authentication 
responder" would be better.

The reason for the whole "authentication timeout" is to ask the 
"original authentication initiator" to do the whole Initial+AUTH again, 
because for some reason the original authentication responder can't do 
it (EAP is one good example).  This fact is not altered by the role 
reversal that happens in rekeying.

Hope this helps.

Yoav

Alejandro Perez Mendez wrote:
> Hi! We need some clarifications about how to know who are the original
> initiator and responder in Repeated Authentication scenario in IKEv2.
>
> The Repeated Authentication document assumes that only the original
> responder can send the AUTH_LIFETIME notification, but after an IKE_SA
> rekeying, the original responder can change (see IKEv2 clarifications
> document section 5.9). After that, the original responder may be
> different to the "original authentication responder" (the peer that acts
> as responder in the IKE_AUTH exchange).
>
> In this case, who is the "original responder" in order to send
> AUTH_LIFETIME notifications?
>
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yoav Nir | 2 May 2006 12:01
Picon
Favicon

Re: Original initiator and responder after an IKE_SA rekeying in Repeated authentication scenario in IKEv2

By "original responder" I mean the party that was Responder in the 
original Initial and AUTH exchanges, so perhaps "original authentication 
responder" would be better.

The reason for the whole "authentication timeout" is to ask the 
"original authentication initiator" to do the whole Initial+AUTH again, 
because for some reason the original authentication responder can't do 
it (EAP is one good example).  This fact is not altered by the role 
reversal that happens in rekeying.

Hope this helps.

Yoav

Alejandro Perez Mendez wrote:
> Hi! We need some clarifications about how to know who are the original
> initiator and responder in Repeated Authentication scenario in IKEv2.
>
> The Repeated Authentication document assumes that only the original
> responder can send the AUTH_LIFETIME notification, but after an IKE_SA
> rekeying, the original responder can change (see IKEv2 clarifications
> document section 5.9). After that, the original responder may be
> different to the "original authentication responder" (the peer that acts
> as responder in the IKE_AUTH exchange).
>
> In this case, who is the "original responder" in order to send
> AUTH_LIFETIME notifications?
>
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 3 May 2006 21:32

draft-housley-gigabeam-radio-link-encrypt-00.txt

http://www.ietf.org/internet-drafts/draft-housley-gigabeam-radio-link-encrypt-00.txt

Pleas take a look at this document.  It makes use of IKE to establish 
cryptographic keys to encrypt a point-to-point radio link.  Review of 
the IKE-related portions of this document from members of this mail 
list would be greatly appreciated.

Thanks in advance,
   Russ
Permalink | Reply | 1 comment |
headers
Tero Kivinen | 4 May 2006 11:29
Picon
Picon
Favicon

draft-housley-gigabeam-radio-link-encrypt-00.txt

Russ Housley writes:
> http://www.ietf.org/internet-drafts/draft-housley-gigabeam-radio-link-encrypt-00.txt
> 
> Pleas take a look at this document.  It makes use of IKE to establish 
> cryptographic keys to encrypt a point-to-point radio link.  Review of 
> the IKE-related portions of this document from members of this mail 
> list would be greatly appreciated.

As this uses only agressive mode the security considerations should
list the known problems with the aggressive mode (i.e. no DH-group
negotiation, no identity protection, no protection against DoS
attacks) and also general problems in the IKEv1, not mentioned in the
RFC2409 because those were found later (some parts of message not
authenticated (header, version rollback, commit bit, vendor-IDs,
initial contact)).

It should also probably try to specify what to do some problematic
cases in IKEv1, i.e. what to do with life times (what to send, what to
accept), how to handle the case that the delete notifications can (and
will) be lost, thus some kind of black hole detection might be needed,
how to recover from various problems (initial contact), how to do the
rekey properly, i.e. when new keying material is negotiated with the
different KEYSEL bit (i.e. different bit in the SPI), when the other
end can switch to use it (i.e. probably both ends install the inbound
handling before the last message, and the responder starts using it
after seeing message 3 of quick mode, and initiator only after it sees
that responder have started using it). There might also need to be
some text explaining how to do the delete of the previous SA cleanly,
as it might happen that the delete for that is lost and that might
cause the next rekey selects wrong SA (there is only 1 bit selecting
(Continue reading)

Permalink | Reply | 0 comments |
headers
dani arisandy | 11 May 2006 06:13
Picon
Favicon

Test Bed IPv6 with IPsec

Dear all,
Right now, I am a college student who is working on my final assignment to graduate from my university. My topic is about the deployment of IPSec in the IPv6 local network. So I build a small network in the lab that contain 4 PCs with Windows XP SP 2 and I PC with Windows Server 2003. I use two of them as routers and the other 2 as clients.
I've read an article that we have to configure the IPSec manually if we want to deploy it on IPv6 network. I've already followed the instructions but still it didn't work. When I try to load the SPD file there is a message "Bad IPv6 Address".
I configured the address of their interface manually by using public address : 2001:0DC6:FF00::/48 and I do subnetting for my test bed.
I've also tried to use the address that Windows give automatically (link local address and site local address). But those address don't change anything, the re is still the message above.
So, is there anyone who knows why?? I am looking forward to the replies for my problems.

Thank you!!!!

Regards,

Dani Arisandy

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. 
_______________________________________________
Ipsec mailing list
Ipsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 0 comments |
headers
Dan Harkins | 13 May 2006 09:22

Re: IKEv1 Security Considerations


  Hi Tero,

  I can't really say I'm too happy with the term "consumed entropy"
either but there is a reason you want to rekey the IKE SA after a
certain number of Quick Mode rekeys.

  You're right that the value of breaking the Diffie-Hellman secret
increases when more keys are derived from it. It also increases when the
information being protected by those keys is high. Regardless though,
you want to rekey the IKE SA after a certain number of Quick Mode
rekeys. Can you articulate a reason why that does not use the words
"consumed" and "entropy"?

  Dan.

> Russ Housley writes:
>> RFC 2409 says:
>>
>>     Repeated re-keying using Quick Mode can consume the entropy of the
>>     Diffie-Hellman shared secret. Implementors should take note of this
>>     fact and set a limit on Quick Mode Exchanges between
>> exponentiations.
>>     This memo does not prescribe such a limit.
>>
>> What limit do implementors impose?
>
> Usually none.
>
> There are quite a many people who do not really agree on that text. I
> do not think entropy really get consumed, but of course the value of
> breaking that one Diffie-Hellman increases when more and more keying
> material is derived from it.
>
> In most implementations IKE SAs do have lifetime that is around few
> hours (from 4-8 hours or so), and using gigabit link with 3DES means
> you need to rekey avery few minutes, which would mean that you would
> be doing around 50 quick mode exchanges before the IKE SA expires.
> The 50 unknown keying materials generated from the same Diffie-Hellman
> secret, should yet give any way to crack that Diffie-Hellman itself.
> --
> kivinen <at> safenet-inc.com
>
> _______________________________________________
> Ipsec mailing list
> Ipsec <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ipsec
>
Permalink | Reply | 0 comments |
headers
The IESG | 16 May 2006 00:39
Picon
Favicon

Last Call: 'GigaBeam High-Speed Radio Link Encryption' to Informational RFC (draft-housley-gigabeam-radio-link-encrypt)

The IESG has received a request from an individual submitter to consider the 
following document:

- 'GigaBeam High-Speed Radio Link Encryption '
   <draft-housley-gigabeam-radio-link-encrypt-00.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2006-06-12.

This document has already received review on the ipsec mailing list,
and the author expects to make changes to address this review:
http://www1.ietf.org/mail-archive/web/ipsec/current/msg02065.html

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-housley-gigabeam-radio-link-encrypt-00.txt
Permalink | Reply | 0 comments |
headers
Randall Solano | 23 May 2006 23:38
Picon
Favicon

Request SCTP over IPSEC

Hello:

I´d like to know if i can use IPsec with SCTP. My
network design is using between MGCs and MGs the
Megaco Protocol, but i don´t if this is correct:

MEGACO/SCTP/IP/IPSEC/ETHERNET/PHYSICAL LAYER 

Other point if i can use SCTP between MGCs different,
like this:

MGC(a)------SigTRAN-------MGC(2)

All of this Protocol stack is:

isup/m3ua/sctp/ip/ipsec/ethernet/physical 

Cheers,

Ran

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
Regístrate ya - http://correo.espanol.yahoo.com/
Permalink | Reply | 2 comments |
headers
Steven M. Bellovin | 24 May 2006 00:17

Re: Request SCTP over IPSEC

On Tue, 23 May 2006 16:38:38 -0500 (CDT), Randall Solano
<solardi_tech <at> yahoo.com> wrote:

> Hello:
> 
> I´d like to know if i can use IPsec with SCTP. My
> network design is using between MGCs and MGs the
> Megaco Protocol, but i don´t if this is correct:
> 
> MEGACO/SCTP/IP/IPSEC/ETHERNET/PHYSICAL LAYER 
> 
> Other point if i can use SCTP between MGCs different,
> like this:
> 
> MGC(a)------SigTRAN-------MGC(2)
> 
> All of this Protocol stack is:
> 
> isup/m3ua/sctp/ip/ipsec/ethernet/physical 
> 
I'm not sure what you mean by "can" you use it.  SCTP with IPsec is
defined in RFC 3554.  However, your stack diagrams are wrong.  IPsec is on
top of IP; if you're using tunnel mode, there's a second IP header on top
of IPsec.  Thus, your first diagram should be

	MEGACO/SCTP/IPSEC/IP/ETHERNET/PHYSICAL LAYER 

for transport mode and

	MEGACO/SCTP/IP/IPSEC/IP/ETHERNET/PHYSICAL LAYER 

for tunnel mode.  (I don't remember which Megaco wants.)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Permalink | Reply | 0 comments |

Gmane