Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8

"Davis, Terry L" <> Tue, 25 August 2009 23:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFA163A6ACC; Tue, 25 Aug 2009 16:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.372
X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xU+NAXuXjYCS; Tue, 25 Aug 2009 16:35:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9C92F3A6A8F; Tue, 25 Aug 2009 16:35:21 -0700 (PDT)
Received: from ( []) by (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7PNYU56006068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Aug 2009 18:34:30 -0500 (CDT)
Received: from (localhost []) by (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7PNYU4n024877; Tue, 25 Aug 2009 18:34:30 -0500 (CDT)
Received: from ( []) by (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7PNYTIP024872 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 25 Aug 2009 18:34:30 -0500 (CDT)
Received: from ([]) by ([]) with mapi; Tue, 25 Aug 2009 16:34:29 -0700
From: "Davis, Terry L" <>
To: 'Stephen Kent' <>
Date: Tue, 25 Aug 2009 16:34:28 -0700
Thread-Topic: [secdir] secdir review of draft-ietf-mext-aero-reqs8
Thread-Index: AcolKTpEqc8kjEfESqeUwuQ4EIDytQAraaew
Message-ID: <>
References: <><> <p06240808c6b8f2972618@[]>
In-Reply-To: <p06240808c6b8f2972618@[]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, "" <>, 'Sam Hartman' <>, "" <>, "" <>, "" <>, "'Ivancic, William D. (GRC-RHN0)'" <>
Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Aug 2009 23:35:22 -0000


Sorry if I confused this issue in this way.  Aviation does not want to be "special" in any area; PKIs or protocols.  And aviation has long recognized that no single PKI will ever serve it; hence our creation of the Exostar Certipath bridge.  By governmental requirements around the globe, we will deal with a multitude of different PKIs and specific key/hash requirements in our environment.  We want to use generic standard Internet services but our security environment will be more demanding than a typical enterprise or agency as we move from OSI to IP for new aviation communications.

Aviation will be the first try (I'm aware of) at utilizing the IP security protocols in a truly dynamic global heterogeneous environment.
- An aircraft will have generally 1 to 4 active communications links at any given time.

- These will change almost continually between service providers and ground portals.

- Some aircraft, especially those that do continuous global circle routes, will have 20 or more service providers for those various links in a 48 hour period.

- Each service provider is likely to have its' own unique security environment and PKI.

- There is no onboard IT staff!  It all has to happen automatically to make new security associations with the next link provider.

Hence my skepticism on our ability to utilize the IP security protocols (regardless how you spell IPSec ;-) in a dynamic global mobile environment.

If the IETF had not adopted the DHCP protocols they were provided with over 15 years ago, we would not have global roaming connectivity today.  No hotspots, no international hotel usage, no laptop portability even between sites within the laptop's own enterprise, etc.  

And providing global "dynamic security association negotiation" is outside of the scope of IETF standards?

To me, not providing a simple "dynamic security association" to insure that our security protocols are fully interoperable and easily implementable in a heterogeneous environment between different vendors would be an abdication of our responsibility to the security of the Internet.

I'll leave at "I think we have some more work to do!"

Take care

PS: You can see some of these same issues in the various CI sectors also as they attempt interoperation of between the various entities within sectors.

> -----Original Message-----
> From: Stephen Kent []
> Sent: Monday, August 24, 2009 7:10 PM
> To: Davis, Terry L
> Cc: 'Sam Hartman';;; 'Ivancic, William D.
> (GRC-RHN0)';;;
> Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8
> At 3:48 PM -0700 8/21/09, Davis, Terry L wrote:
> >Sam
> >
> >One of the items that continues to seriously concern me across the
> >whole IP protocol RFC set is the basic lack of simple
> >vendor-to-vendor IP security interoperability!  All of NEMO and MEXT
> >assumes that simple, easy to implement, IPSec, PKI, and IKE
> >interoperability exist; they do NOT.
> Terry,
> IPsec (not IPSec :-)) and IKE have been available in major host
> operating systems for a few years, so the phrase "easy to implement"
> is not generally a true assertion.  Are you stating that the aviation
> industry needs to implement its own versions of these and analogous
> Interent protocols? Also, as for interoperability, I believe Paul
> Hoffman has reported a number of good results through his VPNC
> testing experiences.
> As for PKI, there are relying party implementations in all browsers,
> and in some OSes, and OpenSSL.  The browsers interoperate with web
> servers (using SSL) developed by a few different vendors, which is a
> decent demo of interoperability for core PKI features. OpenCA and
> OpenSSL are decent (not perfect) examples of open source software for
> both RP and CA functions.
> Later you seem to be arguing that a single PKI (vs. IETF PKI and
> IPsec/IKE standards) is an essential feature for IPsec solutions.
> This is clearly not true in general. Is this another situation where
> aviation is "special?"
> I will not disagree with your assertion that many of the Ipsec/IKE
> and PKI products have hard to configure admin interfaces. But, that
> is an issue outside the scope of IETF standards. Also, I would
> observe that the typical CLI for a router is not an easy to use
> interface either.
> Steve