RE: SACRED's vs. credentials' protection requirements [Was: RE: I -D ACTION:draft-ietf-sacred-reqs-00.txt]

["Linn, John" <jlinn@xxxxxxxxxxxxxxx>]

Al wrote:

> John,
> 
> 	Thanks for your excellent comments.  I've put some 
> responses in-line,
> prefaced by my initials.

Thanks for this response.  Here are some follow-on comments, and a separate
point.

> 
> "Linn, John" wrote:
> > 
> > I'd like to ask a general question about scope.  
> Credentials in their
> > "native" formats, before presentation to a SACRED protocol 
> for transport,
> > may vary widely in terms of the levels of protection they 
> incorporate.  Some
> > may be plaintext, others may be protected with secrets 
> having password-level
> > entropy, and others may be protected with strong 
> cryptographic keys.  It
> > seems clear, e.g., that the level of confidentiality 
> protection functionally
> > required within a SACRED protocol is stronger for 
> credentials provided to
> > SACRED as plaintext than for credentials which are already
> > strongly-encrypted.  Should we specify that the level of 
> protection required
> > to be active within SACRED may vary depending on the 
> characteristics of
> > credentials being input to SACRED?
> >
> 
> AWA: Interesting point - I hadn't directly thought of this before (but
> then, the solutions I've seen all have the property of working with
> homogeneous levels of protection for the credentials with which they
> deal, so it hasn't been an issue).  Yes, this should probably be
> addressed at some point, but I'm uncomfortable with the idea of
> specifying/mandating given security levels - e.g., "if credentials are
> plaintext, be this strong"; "if credentials are strongly protected,
> weakening down to this level is okay".  Those levels are 
> probably going
> to be dictated by the individual environments.  So I think 
> that the best
> we can do in the requirements document is identify that we have to
> support all the cases you mention, and that the protocols have to be
> able to provide varying levels of security, according to the other
> protection provided to the credentials and the environment.

This seems reasonable in principle, but should temper later discussions
about how any MUST-implement protection requirement should be framed for
purposes of conformant interoperability.  Given an environment where
credentials are themselves strongly protected, it could be a strong
deterrent to SACRED adoption if the price of admission were deployment of
additional infrastructure to support an additional layer of key management
which wasn't strictly necessary from a security perspective.

More generally, I think it's important to recognize that protection
facilities enabling secure transfer of credentials can be provided in many
layers, particularly the following:

(1) in the underlying credential format
(2) within a credential transfer protocol like SACRED
(3) in another protocol (e.g., TLS) within which the credential transfer
protocol might be encapsulated

If we focus tightly or exclusively within the SACRED protocol, which seems
an understandably likely result for a WG that's organizationally chartered
to specify that protocol, there's a risk that we'll mandate facilities which
are (sometimes or often) functionally redundant relative to those available
in the other layers.  These incur costs, which may be particularly difficult
to satisfy under some of the initialization scenarios for which SACRED could
be most useful; while individual users will probably invoke SACRED only on
fairly infrequent occasions, those occasions are important ones and may
operate under some tight constraints. I urge, therefore, that the protection
facilities provided within SACRED be modular so as to be effectively
tailorable to correspond to the surrounding layers and operational
environment.  

>  
> > Under 3.1, it's probably hard to come up with an accurate 
> and exhaustive set
> > of vulnerabilities; one which seems to be missing is the case of
> > masquerading as a credential server in order to directly 
> obtain a password
> > which can then be presented by the attacker to the user's legitimate
> > credential server.  (V2 concerns dictionary attack, but 
> here there isn't
> > even any dictionary involved.)
> >
> 
> AWA: True.  The question is, how long a list do we want? We sort of
> wanted some sort of list, to show some examples, but you're 
> right, it's
> probably impossible to come up with an exhaustive list.  We'd welcome
> other input on this topic - should we have such a 
> vulnerability list; if
> so, how complete should we try to make it?  (Assuming we keep 
> the list,
> we'll certainly include the one John mentions above.)

I'm OK with a list of example vulnerabilities, caveated as non-exhaustive,
and think that this is useful and informative material to present.  Rather
than considering them as a separate and different type of requirements,
though, I'd suggest that their implied countermeasures be distilled into
corresponding functional requirements within the existing protocol
requirements sections. 

A separate point: shortly before the end of Sec. 2.1, it's stated that:

   "Solutions involving the direct transfer of credentials from one
   device to another are potentially somewhat more complex than the
   credential-server approach, owing to the large number of different
   devices and formats that may have to be supported. Complexity is
   also added due to the fact that each device may in turn have to
   exhibit the behavior of both a client and a server."

I don't think that the presence or absence of a server influences the number
of client device types that may exist, or the variety of credential formats
they may use. I'm assuming the underlying premise here that the use of a
server may simplify individual clients by making it unnecessary for them to
provide functions to support other client types, at the cost of complexity
present in the server to be able to interact with each of those client
types.  If so, this might be a worthwhile clarification to include.

--jl