Re: [TLS] Please discuss: draft-housley-evidence-extns-00<

[<[e-mail]>]

> The purpose of the proposal is to explore options to
> allow certificate-enabled clients to provide broadcast
> (1-to-many) persistent authentication without having to
> install SOA (WS-*) or other signing-capable plugins on
> the client.  It may or may not be architecturally a better
> choice to do signing through Web Services vs. TLS.  But
> while you're crying crocodile tears over TLS's
> "reputation" should it ever gain the ability to do
> digital signatures, save a few for Vista and digital IDs.
>
> Consumer-to-provider authentication (as opposed to
> consumer-to-provider's-TLS-accelerator) is needed,
> has both benefits and the abuse potential you are
> worried about, and is happening regardless of whether
> TLS is extended.


This is a fascinating interpretation of the purpose of the 
work item. So, lets explore it. I had personally NOT got ANY 
of this from the doc/author-disclosures , so far. Right now, 
it reads as "enforce subpoena on evidence retention". And it 
says, block connections, if you (once authenticated) are not 
clearly authorized and conforming to a mutually agreed data 
retention policy.

But let assume its an "exploration"; i.e. it targets an 
experimental standard status. That I SUPPORT. Why ever would 
one not?

Its for certificate-enabled clients. Well this only includes 
about >50% of the wifi(*) bindings made in the last 5 years 
of explosive wifi adoption by consumers...using EAP-TLS/TTLS 
to generate Russ Housley's TKIP keying material, for RC4 
packet encryption of [TLS/TCP] fragments, by a nic/vlan 
(counter mode with nonce, and CBC-mode mac/mic/moc/muc). 
Given AEAP is entering TLS1.2, we can see connectionless TLS 
coming down the pipe (pun), where after 2**64 bytes, the 
plaintext of the fragment is finally released, post mac 
verification. That I support. Make the TCB's secured data 
store rather large, of course, if you are supporting 1000 
connections! (1000* 2**64)

Said "exploration" is about investigating (I) broadcast, and 
(II) persistent authentication.

Lets take each, one at a time.

Broadcast (1:n): ok I didn't get anything from the text that 
followed, except that its semantics will be ~equivalent to 
WS-Security. I didn't see any furtherance of the broadcast 
notion (which is an interesting term, to me). Presumably, 
given TLS1.2 will accept non-X.509 certs (e.g. SAML2/WS-Fed 
assertions), TLS Evidence will be an alternative to 
SAML/WS-Fed . It will keep the control in the network 
(where, arguably, it belongs). At the same time, if we look 
at the connectionless TLS fragment that comes with AEAP, 
perhaps we do have broadcast keying, in the final/connection 
KDFs?

Persistence:  Are you claiming this to intend to be an 
"https-connection-related stickiness mechanism"?I did NOT 
get this from ANY reading todate. But, its interesting 
(being clearly about "security engineering", at least). This 
would be in scope. They could have said that MORE OBVIOUSLY 
though! Why do I have to work so hard? I'm an awful writer, 
but these guys are Grade A students! That spec was 
beautifully written, apart from gross lack of context.

Consumer-provider: I'll assume here you are making an 
allusion to the writer-to-reader concept from the DoD/NSA 
email world (which started out as something simple: the user 
agent software needs proof of user (I.e. human) presence, 
before rendering the de-ciphered confidential blob in the 
clear on a trusted display). I assume, we are attempting to 
now take that notion and evolve it...to a connection/session 
(versus an connectionless email). I'm interested. (I tried 
years ago, but could not convince you!! to even start 
thinking that we might go there...)


(*) I had one of the earliest UFO-shaped Apple access 
points, that dialed out on a 33k modem upon 802.11 binding. 
I went out and got my own NIC, as I was one of the "wrong 
class" of participant to get one to play with, at an IETF) I 
could never figure its key management scheme was, so never 
turned it on! Apparently, I was one of a million grandpas, 
in this; we all just gave up.


 


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls