Re: [smartpower-interest] Smart Grid Architecture Committee meeting17 February

["Davis, Terry L" <[e-mail]>]

Russ

I agree with you 100% on both the v6 and the security solution; we looked at a similar concept for keying that I liked very much.

I don't think it was on the smartpower lists but on one of the others...  The North American grid system includes 300 million electric meters (just the meters not counting anything else).  That's at least 20 NAT zones to translate between if you use 10 space just for the meters.

I also might suggest that Suite B - circa 2011 be the target as it will have several major changes from NIST.

It might also be of value to actually start working on true vendor-to-vendor interoperability.  SmartGrid like aviation, will likely find that it will have to write into the proposals that simple to implement vendor-to-vendor IPSec/IKEv2 interoperability be provided.

They might also want to take a look at the ATA Spec 42 working on standardizing certificate formats.

Take care
Terry
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> Russ Housley
> Sent: Friday, February 19, 2010 9:29 AM
> To: Fred Baker
> Cc: [e-mail]
> Subject: Re: [smartpower-interest] Smart Grid Architecture 
> Committee meeting17 February
> 
> Fred:
> 
> I have a few comments about IPv6 and security.
> 
> > I am forwarding in case you folks have not seen this. It is 
> the proposed
> > IP architecture from NERC, which is a US regulatory body.
> > 
> > One important statement it makes is:
> > 
> >> A final note is that this document will not make the distinction
> >> between IP version 4 or version 6 for the purpose of analysis or
> >> standardization.  The point is simply to support IP with 
> the version
> >> number left to be an implementation detail determined by 
> the utility
> >> or service provider that would install the AMI network.  That being
> >> said, any competent network planner can easily do the math - many
> >> investor-owned utilities have literally millions of electric meters
> >> installed (a distinct challenge in a version 4 
> environment), with this
> >> "volume problem" being compounded by the presence of other devices
> >> including some quantity of electric vehicles as potential roaming
> >> users in the future.  That means the utility would either 
> have to use
> >> IPv4 very judiciously and replicate private IP space over and over
> >> again, or move to IPv6 and address a greater number of 
> devices uniquely.
> > 
> > This is not as strong a statement re IPv6 as the IETF and ARIN have
> > proposed, but is at least a sensible one in the near term.
> 
> This allows NAT upon NAT.  I would prefer NERC to more 
> strongly advocate
> IPv6.  NERC does not even say that IPv6 is the long-term solution.  I
> wish they had gone that far.
> 
> > The architecture doesn't say a lot about security, but does 
> say this:
> > 
> >> The C12.22 protocol also includes AES-128 security mechanisms.
> >> Additional IP transport security protocols may be provided 
> to enhance
> >> and preserve the upper layer security provisions but not as a
> >> substitute of such.
> > 
> > Personally, I think that's an inadequate statement. The key 
> issues are
> > in identification, authentication, authorization, and 
> confidentiality
> > where appropriate.
> 
> I agree that these are the right security services to include 
> as long as
> you consider access control to be part of authorization.
> 
> 
> > It would be nice if [...] the architecture could specify 
> the use of "suite b
> > cryptographic standards". For those that don't know what 
> that means, it
> > refers to the use of elliptic curve public key cryptography 
> without the
> > IPR considerations that have crippled the industry's 
> ability to use it.
> 
> Suite B is composed of algorithms that are publicly 
> specified, and it is
> defined here: http://www.nsa.gov/ia/programs/suiteb_cryptography.
> 
> Suite B includes:
> 
> Encryption:  AES with 128- and 256-bit keys
> 
> Key Exchange: Elliptic Curve One-Pass Diffie Hellman (called 
> ECDH) using
> the curves with 256- and 384-bit prime moduli
> 
> Digital Signature: Elliptic Curve Digital Signature Algorithm (called
> ECDSA) using the curves with 256- and 384-bit prime moduli)
> 
> Hashing: SHA-256 and SHA-384
> 
> The smaller size in each of these choices seems quite reasonable for
> Smart Grid.
> 
> There are intellectual property issues with Elliptic Curve 
> Cryptography
> (ECC), but McGrew seems to have found at least one way to implement
> these algorithms that avoids the known patents.  See:
> http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01
> 
> > [...] The lack of a key management
> > infrastructure is a problem, which I would entertain useful 
> proposals for.
> 
> As a starting point for this discussion, can we leverage the work done
> by CableLabs and the WiMAX Forum.  Devices that follow the
> specifications from these groups ship with an embedded 
> private key and a
> certificate.  This is not the complete answer, but it allows anyone to
> authenticate the device.  At some point prior to installation, the
> device still needs to be told some things about the network 
> that it will
> be connected.  This might be as simple as the insertion of some
> configuration data that includes a trust anchor to validate 
> certificates
> from the utility.
> 
> Russ
> _______________________________________________
> smartpower-interest mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/smartpower-interest
>