[TLS] charter comparisons, providing wider rationale for GSSAPI

[<[e-mail]>]

If I look at IETF as a whole, we have arguably deviated from the proposed

http://lists.w3.org/Archives/Public/ietf-tls/1996JanMar/0001.html

On the one hand we have successfully borrowed from kerberos some
key management techniques, from the wireless world we borrowed
a little PSK, and may yet be borrowing some more from
GSS_API tokens & MISSI wrapping mechanism. We obviously borrowed
from PKIX and its long line of forbears, though its "NR control"
monster looms, threateningly. Politics has evidently agitated against
more fundamental shifts, to the models of SRP, however,

On the other hand, we experiment with EAP-TLS, where the handshake is
used as a "general purpose authentication" mechanism by PPP - which
is not "above the transport layer" and may exhibit "inappropriate
generalization". If one contrasts EAL-TLS with the originally-proposed
charter, however, it's use offers tribute to the SSL architecture! It
features tuned message pipelining, connectionless fragmentation handling,
custom key derivation, and more. This could all have been specified
much more cleanly, within the architcture, but presumably doctrine got
in the way. One cannot claim that PPP EAP is competing with the
security architecture of IPSEC/ISAKMP and, despite "inappropriate"
generalization of the security handshake and the ciphersuite negotiation, it
is consistent with "secure IP is outside the scope...". That EAP-TLS even
finds itself playing at the link layer is a bid sad, for the internet
security architecture and its designers' judgments.

If we step back, however, what is perhaps missing still is for GSS_API to
now complete Tajer's final mission statement, and specify "SSL token 
exchange"
as an alternative handshake-mechanism, registered using GSSAPI norms.

If SSL adopts GSS-API's negotiation of opaque tokens, there could
be a valuable reciprocity - where GSS-API enables other applications to
use the SSL handshake as a single (negotiable) mechanism - regularizing
what was done essentially in EAP-TLS. I think this would be supported
the MISSI misson, too, moving use slowly towards the additional
benefits of hardware assurance engineering.

I don't like GSSAPI, technically; never have, personally; it always reminded
me of the Nortel/X.509 authentication framework for layer-independent
peer-entity "strong authentication". But, in the IETF tradition, the move I
hint at would be more than technically possible; it would be politically
appropriate. Just as EAP-TLS was done outside TLS WG, this work might
be done similarly beyond, in a nuveau GSSAPI-related work item, if it
struggles to get adopted, here.

----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>
Sent: Friday, December 29, 2006 6:23 PM
Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13

>
>> (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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls