Re: [ekmi] SKML 1.0 Specification - Edited with questions

[Arshad Noor <arshad.noor@strongauth.com>]

You've convinced me, Allen.  We are building an architecture and
protocol for a new archtiecture for securing data, so it makes
sense that we try not to repeat the mistakes made by earlier
design decisions in protocols/software.

What if I modify the <Permissions> element as follows?

1) Instead of making all <Permitted...> sub-elements optional,
   we make them all required, and

2) In addition to allowing the child elements for each of the
   <Permitted....> sub-elements, we add the value "Any" as a
   choice and require that SO's either explicitly create some
   Permission restriction, or use the keyword "Any" so they
   recognize what they are doing.

If we do that, the <Permissions> element might now look like the
following (one example which has no Permission restrictions - the
same as an empty <Permissions> element based on DRAFT 5.1):

<Permissions>
  <PermittedApplications>Any</PermittedApplications>
  <PermittedDates>Any</PermittedDates>
  <PermittedDays>Any</PermittedDays>
  <PermittedLevels>Any</PermittedLevels>
  <PermittedLocations>Any</PermittedLocations>
  <PermittedNumberOfTransactions>Any</PermittedNumberOfTransactions>
  <PermittedTimes>Any</PermittedTimes>
  <PermittedUses>Any</PermittedUses>
</Permissions>

Another might look like the following that restricts keys to only a
1,000 encryption transactions and only on weekdays for one specific
application:

<Permissions>
  <PermittedApplications>
     <PermittedApplication>
       <ekmi:ApplicationID>10514-23</ekmi:ApplicationID>
       <ekmi:ApplicationName>eCommerce Application</ekmi:ApplicationName>
       <ekmi:DigestAlgorithm>http://www.w3.org/2000/09/xmldsig#sha1</ekmi:DigestAlgorithm>
       <ekmi:DigestValue>NIG4bKkt4cziEqFFuOoBTM81efU=</ekmi:DigestValue>
     </ekmi:PermittedApplication>
  </PermittedApplications>
  <PermittedDates>Any</PermittedDates>
  <PermittedDays>Weekdays</PermittedDays>
  <PermittedLevels>Any</PermittedLevels>
  <PermittedLocations>Any</PermittedLocations>
  <PermittedNumberOfTransactions>1000</PermittedNumberOfTransactions>
  <PermittedTimes>Any</PermittedTimes>
  <PermittedUses>Any</PermittedUses>
</Permissions>

While this makes the protocol just a tiny bit heavier, it does make
the policy explicit so that no one can complain that they did not 
know the SKMS would allow keys to be used by any application, at any
time, etc.

Additionally, IT Auditors would have a way of zeroing in on key-use
policies that had an "Any" value for all <Permitted....> sub-elements
as it might indicate a weakness in policy implementation.

What deos everyone think?

Arshad

P.S.  I will add the other information (default-deny rule, and the
FAQ to the non-normative document later, but would like to focus on
teh normative specification first as it is more important.

----- Original Message -----
From: "Allen" <netsecurity@sound-by-design.com>
To: "Arshad Noor" <arshad.noor@strongauth.com>
Cc: "ekmi@lists.oasis-open.org >> ekmi" <ekmi@lists.oasis-open.org>
Sent: Thursday, June 19, 2008 10:24:41 PM (GMT-0800) America/Los_Angeles
Subject: Re: [ekmi] SKML 1.0 Specification - Edited with questions

Arshad Noor wrote:
> Allen,
> 
> You raised a couple of interesting questions in your edited version of
> the spec.  I decided to answer it separately in an e-mail rather than
> put the answer in the document.  I'll quote the sections with your
> questions for those who haven't had the time to review the document.
> 
> Question 1:
> 
> "When the <Permissions> element is empty, that there are no restrictions 
> on the use of the symmetric key other than that the application calling 
> on the SKCL be authorized to access the key in question. However, when 
> there are elements defined within the <Permissions> element, conforming 
> SKCL implementations must comply with all the permission elements, 
> evaluating the most restrictive permissions first and in decreasing 
> order of restriction, before allowing the use of the key.
> 
> [Allen's question] (This approach has a potential flaw if there is any 
> misconfiguration. It implicitly allows that which is not denied rather 
> than denying everything that is not explicitly allowed. Granted, it is a 
> bit more cumbersome to require that all permissions be explicit, but it 
> is more secure when such events as typographical errors occur in that it 
> will fail when attempts to utilize a key are made, rather than silently 
> allowing the error and it only showing up in logs or other events)."
> 
>   I thought about the implications of this design for quite some time
>   before settling on this, Allen.  Let me explain my rationale: an SKS
>   Server, by default, will NOT return an existing key to any client
>   unless there is an explicit authorization to that key (or KeyGroup)   
>   for the specific client (or the Group to which the client belongs).
>   Since the key is denied by default, it is my belief that the risk of
>   returning an existing key to a client, by mistake or omission, is
>   very little.

If it is as you say, "...by default, [ an SKS Server] will NOT 
return an existing key to any client..." then that should be noted 
at the appropriate place in the documentation.
> 
>   WRT the <Permissions> element, it is my belief that the vast majority
>   of applications will not have the severe restrictions imposed by this
>   element & sub-elements, in the early stage of encryption.  Some high-
>   risk data will need to be protected significantly, and the keys that
>   protect that data will have the detailed <Permission> elements around
>   their use-policy.  As such, I believe that SO's will want to define
>   those highly-restrictive policies only for the few use-cases where it
>   is necessary.  For all other keys, the default-deny rule is more than
>   sufficient protection.  Wouldn't you agree?

Well, in all honesty, no. My logic is simple. If mistaken 
understanding of how to properly configure something is possible, 
then misconfiguration will happen, without fail. What's worse is 
that it will most likely happen at the point where there is the most 
pressure to get it right.

In general - this is, of course, a philosophical viewpoint about 
proper design - I believe that much like product safety for 
children's clothing, one should assume the worst and protect based 
on that assumption. A classic example of this occurred the other day 
in a day care center. The toddler was wearing a "hoodie" with a 
drawstring closure that got caught on the play structure and 
strangled to death. Was it a common occurrence with many deaths? No, 
not at all. Were there better designs available? Yes. Did the 
parents and the child care provider adequately foresee the 
possibilities? No. Is it reasonable that they should have? I don't 
think so.

In much the same manner it will not always be the best and brightest 
who will implement the SKML standard. Given this, I think a fail 
safe design is better.

Also looking at the metric I saw recently that at the current level 
of coding, about 500,000 bugs are created per year, but we are only 
stamping out 50,000 per year. This does not mean that the bugs are 
all that serious or even threaten security, but we do not know what 
they do and may not until they suddenly become newspaper headlines 
like the ATM attack that was just mentioned. Who knew it was 
possible? I sure didn't and I have looked at the ATM model fairly 
closely.

All that aside, this is more of a coin flip choice. I don't think it 
is all that big a deal, I just wouldn't do it that way.

> Question 2:
> 
> "NOTE:  It is noteworthy to mention that the absence of a 
> <PermittedDuration> element within a <KeyUsePolicy> element specifies 
> that applications are permitted the use of the symmetric key forever, 
> subject to complying with all other permission clauses in the 
> <KeyUsePolicy> element, if any.
> 
> [Allen's comment] (This is bad design as all processes should have a end 
> by date by default, requiring re-authorization so that nothing operates 
> out of sight, out of mind)"
> 
>   It is my belief that most keys will have restrictions on their use
>   in one form or another.  Either they will be restricted by dates,
>   time, duration, transactions or something that will limit its use
>   forever.  It is unlikely that any SO will want a symmetric key to be
>   used for encryption, forever.  A good SKMS/EKMI architect will ensure
>   that SO's are aware of this when defining their KeyUsePolicies.

Well, as we well know there are good security people and good 
security people. Again, it is a matter that could be missed by some 
because they aren't paying attention to the implications at the 
exact moment they are looking over the specific code lines because 
of a thousand and one reasons, the phone rings, they are thinking of 
the hot date they will have later, whatever.

>   Like anything really dangerous - guns, dynamite, matchsticks, etc. -
>   one needs to train people on their proper use.  You can't protect
>   them from harming themselves if they don't heed your advice.

All too true, but experience has taught us to design guns with 
safeties, less sensitive dynamite, safety matches and restrict the 
more hazardous versions to people with more experience, and even 
they get killed. Nothing is perfect or fool proof. (There is a 
wonderful folk tale about a boy and a fool killer told by Pete 
Seeger, I believe, that lists all types of fools to avoid.)

>   It would be helpful in understanding this model, if you see that the
>   <Permission> element and its sub-elements are *further* restrictions
>   on the default-deny policy of an SKS server (at least in StrongKey,
>   it is so; I'm not sure how other KM systems implement their policies).
>   The risk is already mitigated at the very first gate; once you get
>   past that, there may be other restrictions that conforming SKCL
>   implementations must address.

I trust that you have done it right, Arshad, but..., there is this 
little voice that says to me, "It's a standard so spell it out and 
leave nothing to chance."

> Hope these address your questions, Allen.  Thanks for the really fast
> turnaround on the DRAFT 5.0 normative document.  Do you - or others
> from the TC - have any suggestions for improving the DRAFT 5.0
> informative document?  Should these explanations be in there?  Should
> we include a FAQ section in the informative document that highlights
> these questions/comments?

Yes, a FAQ is most appropriate, and probably the right place for the 
points above to be covered as well as any other issues that might be 
thought of.

Best,

Allen