Subject: RE: [Mipshop] AW: [Mobopts] Presentation slides for "CXTP using GIST"

From: "COMBES Jean-Michel RD-MAPS-ISS" <[email-masked]>
Date: Wed, 23 Nov 2005 13:04:45 +0100

Hi, 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James Kempf
> Sent: Tuesday, November 22, 2005 6:04 PM
> To: Tschofenig, Hannes; DENG, HUI -HCHBJ; Xiaoming Fu; 
> [email-masked]; [email-masked]
> Cc: Xiaoming Fu
> Subject: Re: [Mipshop] AW: [Mobopts] Presentation slides for 
> "CXTP using GIST"
> 
> IPsec context is pretty much out, unless what is exchanged 
> does not involve the shared key. So is any AAA context that 
> involves a shared key. Please see 
> http://www.ietf.org/internet-drafts/draft-housley-aaa-key-mgmt
> -01.txt for a discussion of why propagating shared keys in 
> this manner is not secure. 

BTW, IMHO, there are no clear reasons/arguments, about why propagating shared keys in this manner is not secure, in this draft ....

> The draft talks specifically about 
> AAA-derived keys, but could as well be applied to IPsec derived keys.
> 
>             jak

Cheers.

JMC.

France Telecom - R&D Division - MAPS/NSS   
Jean-Michel COMBES, Internet/Intranet Security
E-Mail: [email-masked]
Phone: +33 (0)1 45 29 45 94
Fax: +33 (0)1 45 29 65 19
Mobile: +33 (0)6 07 29 30 16 

> 
> ----- Original Message -----
> From: "Tschofenig, Hannes" <[email-masked]>
> To: "DENG, HUI -HCHBJ" <[email-masked]>; "Xiaoming Fu" 
> <[email-masked]>; <[email-masked]>; <[email-masked]>
> Cc: "Xiaoming Fu" <[email-masked]>
> Sent: Monday, November 21, 2005 5:23 AM
> Subject: [Mipshop] AW: [Mobopts] Presentation slides for 
> "CXTP using GIST"
> 
> 
> > hi hui
> >
> > there are two issues to discuss:
> >
> > a) which security mechanisms you use for protection of the context 
> > transfer between the old ar and the new ar.
> >
> > b) which context you transfer between these devices.
> >
> > i could not remember xiaoming and john proposing to 
> transfer ipsec sas as 
> > part of (b). if you would like to transfer ipsec sas then the past 
> > investigations in, for example, 
> <draft-hk-seamoby-ct-ipsec-00.txt> or 
> > <draft-gopal-seamoby-ipsecctxt-issues-01.txt> might be 
> worth taking a 
> > look.
> >
> > ciao
> > hannes
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: [email-masked]
> >> [mailto:[email-masked]] Im Auftrag von DENG, HUI -HCHBJ
> >> Gesendet: Montag, 21. November 2005 14:05
> >> An: Xiaoming Fu; [email-masked]; [email-masked]
> >> Cc: John Loughney; Xiaoming Fu
> >> Betreff: RE: [Mobopts] Presentation slides for "CXTP using GIST"
> >>
> >> Hi, Xiaoming
> >>
> >> I am still wondering how could you handle IPsec SA transfer,
> >> expecially initialize vector and anti-replay window.
> >>
> >> Thanks
> >>
> >> -Hui
> >>
> >>
> >> -----Original Message----- 
> >> From: Xiaoming Fu [mailto:[email-masked]]
> >> Sent: 2005-11-20 (星期日) 3:10
> >> To: [email-masked]; [email-masked]
> >> Cc: John Loughney; Xiaoming Fu
> >> Subject: [Mobopts] Presentation slides for "CXTP using GIST"
> >>
> >>
> >>
> >> Hi all,
> >>
> >> Due to time limitation, mostly the Q&As in response to
> >> some reviewers'
> >> comments were discussed in the MOBOPTS RG meeting. For
> >> anyone interested
> >> in this draft, the slides are available in the following link:
> >>
> >> http://user.informatik.uni-goettingen.de/~fu/temp/cxtpgist/CXT
> > PusingGIST_IETF64.ppt
> >>
> >> Please drop me/us a message if you think it may be
> >> useful, or any
> >> (additional) comments/suggestions you might have.
> >>
> >> Cheers,
> >> Xiaoming
> >>
> >> _______________________________________________
> >> Mobopts mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/mobopts
> >>
> >> +zy'���+jwbƭ!'ڟ&y'~'^ؚݙz-y֧ںh,v!zz+vb隊V+-jGz���޶ʋ^{^ם"'^jǧ
> >> 
> ؟^ze隊V'jhțuץzע*.&^̬颚g^+az~׫!ޞm觵yr*bz{r鮲)b隊Z+jZr+v+{^-^ֆ)^Zuz}+$yh޷
> >> +y޲'&+r~ڟ'(z0'!(!}y~b
> >>
> >
> 
> 
> --------------------------------------------------------------
> ------------------
> 
> 
> > _______________________________________________
> > Mipshop mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mipshop
> > 
> 
> 
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 
_______________________________________________
Mobopts mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts

---

From: "James Kempf" <[email-masked]>
Date: Wed, 23 Nov 2005 08:06:30 -0800

Section 4:

      Prevent the Domino effect

         Compromise of a single peer MUST NOT compromise keying material
         held by any other peer within the system, including session
         keys and long-term keys.  Likewise, compromise of a single
         authenticator MUST NOT compromise keying material held by any
         other authenticator within the system.  In the context of a key
         hierarchy, this means that the compromise of one node in the
         key hierarchy must not disclose the information necessary to
         compromise other branches in the key hierarchy.  There are many
         implications of this requirement; however, two implications
         deserve highlighting.  First, the scope of the keying material
         must be defined and understood by all parties that communicate
         with a party that holds that keying material.  Second, a party
         that holds keying material in a key hierarchy must not share
         that keying material with parties that are associated with
         other branches in the key hierarchy.

If keys are propagagted by context transfer, compromise of one router/AP 
causes compromise of all.

            jak

----- Original Message ----- 
From: "COMBES Jean-Michel RD-MAPS-ISS" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Tschofenig, Hannes" 
<[email-masked]>; "DENG, HUI -HCHBJ" <[email-masked]>; 
"Xiaoming Fu" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: "Xiaoming Fu" <[email-masked]>
Sent: Wednesday, November 23, 2005 4:04 AM
Subject: RE: [Mipshop] AW: [Mobopts] Presentation slides for "CXTP using 
GIST"

> BTW, IMHO, there are no clear reasons/arguments, about why propagating 
> shared keys in this manner is not secure, in this draft ....
>