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
- [TLS] WGLC: draft-ietf-tls-srp-13 EKR
- Re: [TLS] WGLC: draft-ietf-tls-srp-13 Peter Sylvester
- RE: [TLS] WGLC: draft-ietf-tls-srp-13 Peter Williams
- Re: [TLS] WGLC: draft-ietf-tls-srp-13 EKR
- Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 Mike
- [TLS] Re: WGLC: draft-ietf-tls-srp-13 Simon Josefsson
- Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 Bodo Moeller
- Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 home_pw
- Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 home_pw
- Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 home_pw
- Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 home_pw
- Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 home_pw
- RE: [TLS] Re: WGLC: draft-ietf-tls-srp-13 Pasi.Eronen