Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13

<home_pw@msn.com> Sat, 30 December 2006 02:23 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0TsR-00068l-To; Fri, 29 Dec 2006 21:23:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0TsR-00068d-2V for tls@ietf.org; Fri, 29 Dec 2006 21:23:15 -0500
Received: from bay0-omc3-s33.bay0.hotmail.com ([65.54.246.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0TsP-00016t-NP for tls@ietf.org; Fri, 29 Dec 2006 21:23:15 -0500
Received: from hotmail.com ([65.54.174.86]) by bay0-omc3-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 29 Dec 2006 18:23:12 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 29 Dec 2006 18:23:13 -0800
Message-ID: <BAY103-DAV1456A137B54423E6CB261C92C50@phx.gbl>
Received: from 69.227.152.254 by BAY103-DAV14.phx.gbl with DAV; Sat, 30 Dec 2006 02:23:10 +0000
X-Originating-IP: [69.227.152.254]
X-Originating-Email: [home_pw@msn.com]
X-Sender: home_pw@msn.com
From: home_pw@msn.com
To: tls@ietf.org
References: <BAY103-DAV4BF9EC54383E84FC677FB92C60@phx.gbl> <BAY103-DAV30366D530EC702791273892C60@phx.gbl>
Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13
Date: Fri, 29 Dec 2006 18:23:24 -0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223
X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223
X-OriginalArrivalTime: 30 Dec 2006 02:23:13.0018 (UTC) FILETIME=[74B2FDA0:01C72BB9]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

> (as FIPS 800-56B drafts are not available to the likes of me.)


I've been attempting to deconstruct what I understand NIST's position on
next generation RSA ciphersuites to be (from what I assume 800-56B to say):-

Based on the way 800-56A discusses the role of RSA (or other) key transport.

One uses DH in the users' national identity cards to agree a random
secret,  which has the important property of "bi-lateral key confirmation"
implicit to the math of the DH/KEA etc. This agreement process may include
certain DH ephemerals in addition to statics, and a UKM nonce. This process
satisfies the writer-to-reader rules.

One may use RSA as an IK to transport to several parties the "secret" value 
to
the authorized HSMs associated with one or more user (e.g. one's TPM-based 
SSL CSP,
or a broadcast community of HSMs). The crypto device uses a 
parameterized-KDF to
transform the value into a KEK, which unwraps the keying materials (and mac 
secrets)
used in the SSL HSMs. Presumably, the KDF enforces TPM assurance controls, 
preventing
key derivation when the secret is not assured to be from authorized id cards 
(validated
using "tri-lateral key confirmation" using some unstated method (e.g. HSM 
certs)).

"Key confirmation" would have to be trilateral, if there is key confirmation
by a "third party" - the community of authorized crypto devices.

The final KDF (per connection) in SSL finished protocol takes into account 
the roles
of the 2 or more SSL  parties, currently hashes of the terms "client" and 
"server"

------------

For fun one can extrapolate, doctrinally:-

One can define a role for TLS Evidence, which exist to audit such 
handshakes, using
a dig sig of the handshake hashes (and store the handshake plaintexts).
Presumably, the router/ISP can enforce policy to (a) interdict certain flows 
(b) record
certain auditable handshake plaintexts. 


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls