Re: [smartpowerdir] Summary of Smart Power matters July 2010

Sam Hartman <> Sun, 25 July 2010 10:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7047B3A68F8 for <>; Sun, 25 Jul 2010 03:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CBm6bqNqeMtc for <>; Sun, 25 Jul 2010 03:32:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C14463A68FD for <>; Sun, 25 Jul 2010 03:32:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by (Postfix) with ESMTPS id B8C84203C7; Sun, 25 Jul 2010 06:33:02 -0400 (EDT)
Received: by (Postfix, from userid 8042) id 21ED44133; Sun, 25 Jul 2010 06:32:59 -0400 (EDT)
From: Sam Hartman <>
To: IETF SmartPower Directorate <>
References: <> <> <>
Date: Sun, 25 Jul 2010 06:32:59 -0400
In-Reply-To: <> (Fred Baker's message of "Sun, 25 Jul 2010 05:54:07 +0200")
Message-ID: <>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Margaret Wasserman <>, IAB <>
Subject: Re: [smartpowerdir] Summary of Smart Power matters July 2010
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Members of the Smart Power Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Jul 2010 10:32:53 -0000

>>>>> "Fred" == Fred Baker <> writes:

    Fred> i) As you may be aware (I was not), security in the HAN is at
    Fred> the moment being derived from 802.1X using EAP-TLS (RFC 5216)
    Fred> at the link layer. In short, devices that enter the HAN should
    Fred> be those that are authorized access. A comment I got from a
    Fred> NIST security architect (Justin Searles) said that was the
    Fred> best security available today. It gives me some concern,
    Fred> however, as the fact that one is authorized to use a network
    Fred> doesn't mean one is authorized to do anything in particular in
    Fred> the network - the fact that I can attach my laptop doesn't
    Fred> mean I can reconfigure the routers, for example. I'd be
    Fred> interested in other views...

Fred, can you point me at documents discussing this in more detail?
So far I've been unable to determine:

* Where device certificates come from and how they are chained back to a
  trust anchor that the EAP server knows

* How the EAP server gets a certificate that chains back to a trust
  anchor that the device knows

* How the EAP server authorizes devices

* How the device authorizes EAP servers

I'll admit that eap-tls seems at first glance like a singular
inapplicable technology in this space. That may well be my iniability to
imagine how this is all going to be deployed, so any assistance in
understanding would be greatly appreciated.