RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to create integrity-assured metadata

["Mark Brown" <[e-mail]>]

Peter,

> > 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. 

I can see how TLS Evidence could be used as David suggests in his terse
comment about: "(1-to-many) persistent authentication".  You're right we
haven't talked about this use of TLS Evidence before.

One use for the TLS Evidence two-signature approach is to generate
integrity-assured data and metadata.  Integrity-assured data/metadata is a
create-write-once, read-many thing, and could be considered "(1-to-many)
persistent authentication".  TLS Evidence can be verified by any third
party, so if you choose to share it in this way, many could read it.
Obviously the choice to share data should be made in light of legal and
moral obligations stemming from the data contents.  TLS Evidence is content
agnostic.  But for the case of integrity-assured data/metadata, perhaps it
is useful to transmit and share TLS Evidence in addition to persisting it as
an audit trail.  So far we've really only talked about the audit trail uses
(and potential abuses) of TLS Evidence where (presumably) very few should
read it.

For example, if any of the final recipients are not attached via trusted
connection to the TLS server (for example, if any of the recipients are not
on the box with the TLS server, or if you just can't trust the connection
for some other reason), those recipients might benefit from integrity
assurance / proof of origin for the data/metadata that was received.  This
may be relevant to the TLS accelerator scenario David mentions.  In that
case an app may feel a little queasy about the client's identity since the
app never gets let in on -- and has no recourse to -- the client
authentication process.

Here's an integrity-assured data and metadata creation scenario.  A note for
clarity: a sender usually only writes metadata when that sender is also
writing data (i.e. sender is writing/sending but not reading/retrieving).
In the TLS Evidence two-signature approach, the sender might not be highly
assured, but provides a sender's-signature over the data and metadata.  The
sender's signature supplies provenance data, proving the origin was this
particular sender.  Additional knowledge of/about the source (via the
source's PKC or some other trusted records) may help qualify "who" sent it
and "what" is being sent.  For example, the PKC or trusted records
pertaining to the PKC might indicate the sending machine (physical location,
classification level, sensitivity level, hardware and software in use, etc.)
and the originating PKC may also imply the sending user (sender's rank,
sender's role, sender's authorizations, etc.).  

Of course the sender could use any digital signature method and achieve the
same result as what has been described so far.  TLS Evidence might add some
convenience.  But an assurance transformation in TLS Evidence happens when
the sender's transmission is authorized / granted access by the receiver.
Obtaining high assurance is the main goal in this scenario.

When the receiver performs the act of access control, for example if the
receiver uses a separation kernel to enforce mandatory information flow
policies, then the receiver's countersignature can add value.  Just about
any kind of access control works here.  The receiver does not have to
send/receive "authorizations" here -- it is common for just client
authentication results to be sufficient to decide whether to allow or deny
access.  All of this happens naturally in TLS handshakes; whether you use
mutual authentication, TLS Authorizations, etc., the protocol generates
fatal alerts if any step fails or loosely speaking, isn't good enough.  So
naturally in TLS you can't generate TLS Evidence until the handshake
completes successfully, which implies that access is allowed and
application_data can flow.  

To the level (only to the level) that the access control / information flow
policy enforcement can be trusted, that is the value of the
countersignature.  For example, if the receiver is subverted, then the
receiver's countersignature adds no assurance.  Even if the receiver seems
likely to be subverted, still the countersignature adds little assurance.
If on the other hand the receiver is EAL6 or EAL7, then you have a high
degree of confidence that the information flow was authorized.  EAL6 or
better is what's in view for integrity-assured metadata.  

The receiving router is never expected to be able to interpret the data or
the metadata.   Instead the receiver only verifies that current policy
allows the sender's requested information flow (access control check) and
that the sender's signature is correct.  Those verifications are its only
job.  If verified, then the receiver's signature (aka countersignature)
transforms the sender's metadata into integrity-assured metadata;
countersignature adds assurance to the metadata and data asserted by the
(now) authorized sender-source.  

So, in the case of a write of data and metadata, you know who wrote it
(sender's digital signature and receiver's validation of the computation's
correctness) and you know exactly what was said, but now (upon
countersignature) you also know that the write was _authorized_ (in a
military case, by policy).  So it is correct to infer the sender had the
authority to create both the data and the metadata.  When you have high
assurance that sender was authorized to write this data & metadata, and the
data & metadata is digitally signed, then no matter what the contents are, a
lot of worries about forged data / metadata go away.  Doubts may still exist
i.e. that this twice-signed stuff may be the perfect preservation of the
sender's erroneous misstatements or lies, but it is certainly NOT
unauthorized.  However, if the sender repeatedly speaks lies, it would be
very easy to change the policy for that sender, revoking that sender's
authorization.  Relying on this natural feedback loop, TLS Evidence
purposefully and absolutely separates itself from the task of discerning
lies, misstatements, sender's intent, etc.  In other words, TLS Evidence
NEVER looks into the application data.  

The two-signature approach follows from other useful security
models/methods.  You could see the two-signature approach as dual controls.
You could call it separation of duties.  I have compared its design to John
Rushby's 1981 proposal for the "separation kernel" as different from a
"security kernel".  Lawyers I have spoken to indicate that the two-signature
approach seems fair and not biased towards either sender or receiver.  All
of these are my goals.  The point is that in TLS Evidence each signature
accomplishes something different, and nothing can be accomplished by only
one signature.  This is useful when you want to avoid all-powerful keys (if
you believe as I do that such keys can be dangerous).

The policy question here is, How can we limit and focus what we authorize
subjects to "say" so that they are never authorized to "say" stuff that will
hurt the policymaking organization?  Policy makers should try to put only
those sorts of authorizations on the whitelist, and not for example
introduce broad, sweeping authorizations that apply to a large group of
nearly anonymous subjects.  Pinpoint accuracy when building the
authorizations whitelist is the preferred policymaking approach.  

Benefits / Commercial Application
Integrity-Assured Metadata (IAM) can be used to label data with a range of
classification levels, sensitivity levels, integrity levels, origin and
other information and tags.  IAM can provide useful and trustworthy metadata
to inform personnel and systems, which in turn can improve efficiencies and
accuracy.  Correctly formulated IAM should be useful outside of the context
of the originating system and/or a high assurance intermediary;
specifically, IAM should be especially useful to applications and consumers
after it has exfiltrated from a secure originating system.  IAM may help
enable MILS solutions to scale beyond a single processor system.  IAM can be
assembled into histories to describe who / what / when for access,
transmission and processing for an object.  IAM is a tagging, sharing,
searching, publishing aid that can help enable the data-sharing "post before
processing" paradigm proposed in DoD Directive 8320.2.  Metadata, including
security IAM, is widely applicable to numerous military and commercial
systems.

--mark


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