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 17:59:24 +0100

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Wednesday, November 23, 2005 5:31 PM
> To: COMBES Jean-Michel RD-MAPS-ISS; 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"
> 
> I am not sure I understand the question. If you mean "why 
> would an attacker want to compromise a network in this 
> manner", I must confess I am not an expert on the criminal 
> mind, so I can't really answer the question.

:)

> If you mean "how 
> would an attacker accomplish such a compromise", 

Yes, sorry.

> it would 
> require either that the network operator is negligent, or 
> possibly as an inside job.

Compromises are based either on software or on human faults, right?

As you know, when an operator deploys a technology, most of the time, he uses products from one or two manufacturers. So if one product is compromised, all the entities from the same product can be or are comprised.
In the same case, if this is human-based compromise, most of the time, if this guy can access to one entity, he can access to all the entities of the same administrative domain.
On the other side, Context Transfer only occurs in a same administrative domain (cf. CXTP requirements).

So I don't see what is the danger to set up a rule saying "No CXTP for security". But maybe I am wrong and would be happy to know why :)

>             jak

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: "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 8:19 AM
> Subject: RE: [Mipshop] AW: [Mobopts] Presentation slides for 
> "CXTP using GIST"
> 
> 
> > Hi,
> >
> > What are the reasons of such a compromise?
> >
> > 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: James Kempf [mailto:[email-masked]]
> >> Sent: Wednesday, November 23, 2005 5:07 PM
> >> To: COMBES Jean-Michel RD-MAPS-ISS; 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"
> >>
> >> 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"
> >>
> >>
> >> > 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 09:05:54 -0800

> As you know, when an operator deploys a technology, most of the time, he 
> uses products from one or two manufacturers. So if one product is 
> compromised, all the entities from the same product can be or are 
> comprised.
> In the same case, if this is human-based compromise, most of the time, if 
> this guy can access to one entity, he can access to all the entities of 
> the same administrative domain.

Well, just taking a stab at this, I don't think it really has much to do 
with bugs in a product. Even if the product is completely bug-free and the 
operator's network management processes are spotless, there is still the 
factor of human nature. A trusted employee might wake up on the wrong side 
of bed one day and decide to play some tricks.

> So I don't see what is the danger to set up a rule saying "No CXTP for 
> security". But maybe I am wrong and would be happy to know why :)
>

Perhaps you can send email to Russ and Bernard? They might be able to do a 
better job of explaining it that I can.

            jak