Re: [secdir] Secdir review of draft-altmann-tls-channel-bindings-10

["Avygdor Moise" <[e-mail]>]

Without going into too much detail I will try and explain what is meant by 
"only to enhance and preserve [and] ... not be a substitute for ... ANSI 
C12.22 ... security provisions."

ANSI C12.22 / IEEE 1703 / MC12.22 can use any network transport protocol to 
carry a C12.22 Message.
Because of the above expectation the protocol can not assume that the 
underlying transport is secure, although it may be.

A C12.22 Message is composed of three core components:

1) Connectionless-mode ACSE APDU wrapper
2) EPSEM service/response indication
3) ANSI C12.19 / IEEE 1377 / MC12.19 Table Data (for EPSEM Read/Write 
services)

ANSI C12.22 / IEEE 1703 / MC12.22  supports the transmission of the ACSE PDU 
using one of thee "standard modes"

1) Mode 0 -- The C12.22 Message is transmitted in clear text without 
encryption and without authentication.
2) Mode 1 -- The C12.22 Message is transmitted in plain text without 
encryption, but with authentication.
3) Mode 2 -- The C12.22 Message is transmitted encrypted and authenticated.

The default (build-in) mechanism is EAX' (based on AES-128).
In addition the protocol implements duplicate APDU rejection,  playback 
rejection and message associations.

The "built-in" C12.22 Security Mechanism is registered as Module 
C12.22-Security-Mechanism {iso(1) member-body(2) us(840) 
c1219-standard(10066) mechanism(12) c1222(1) version(1)}

Other encryption/authentication protocols may be registered by providing an 
algorithm and an OID.

In addition EPSEM security service together with ANSI C12.19 / IEEE 1377 / 
MC12.19  passwords and roles tables role-base accessed to data and services.
When authentication and/or encryption is used then the ENTIRE ACSE APDU is 
authenticated including all source/destination elements.

If a network manager wishes to introduce additional security (e.g. TLS, 
Firewalls etc.) then this should not act to replace the security cited 
above, because the C12.22 Message "contract" is an end-to-end. i.e. a C12.22 
Message may enter and leave an IP network, but when it does then the C12.22 
Message integrity, security, privacy and authenticity should not be affected 
by the presence or absence of an IP network or the presence or absence of IP 
network security.

If the IP security introduces additional opacity (privacy) then it may be 
necessary to install additional C12.22 Relays/Gateways at the perimeter of 
the secured IP network, when the network attaches to a global AMI network.

I hope this clarifies things
Avygdor Moise

----- Original Message ----- 
From: "Paul Hoffman" <[e-mail]>
To: "Magnus Nyström" <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
Sent: Sunday, June 27, 2010 3:44 PM
Subject: Re: [secdir] Secdir review of draft-altmann-tls-channel-bindings-10


Given that I have made this same copy-and-paste error in the past: this 
review is for draft-c1222-transport-over-ip, not the one in the Subject: 
line.

At 10:31 AM -0700 6/27/10, Magnus Nyström wrote:
>I have reviewed this document as part of the security directorate's
>ongoing effort to review all IETF documents being processed by the
>IESG.  These comments were written primarily for the benefit of the
>security area directors.  Document editors and WG chairs should treat
>these comments just like any other last call comments.
>
>This document defines a framework for transporting ANSI C12.22
>advanced metering infrastructure (AMI) messages on IP networks.
>
>AMI is intended for interaction with various types of utility meters;
>as such, it is clear that security services such as data authenticity,
>integrity and confidentiality will be quite important.  This draft
>defers to ANSI C12.22 for application-layer security and states that
>any transport (or IP) network layer security security functionality
>shall act "only to enhance and preserve [and] ... not be a substitute
>for ... ANSI C12.22 ... security provisions." This is all good but I
>have not had access to C12.22 for this review and so cannot comment
>further on it. It seems to me, however, that the layering of C12.22
>on top of IP networks may warrant a discussion about potential methods
>to enhance C12.22 security? For example, could privacy be enhanced
>beyond what C12.22 offers through use of a transport network's
>confidentiality services?
>
>Other than this I have no particular comments on this draft; it reads
>good to me.
>-- Magnus
>_______________________________________________
>secdir mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/secdir