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

From: "Linn, John" <[email-masked]>
Date: Thu, 9 Nov 2000 10:42:06 -0500

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Nov 2000 18:59:20 +0000

Hi John,

[snip]
> which wasn't strictly necessary from a security perspective.
[snip]

You're right that there will be cases where using whatever ends up as 
the standards track SACRED protocol will require overhead that isn't 
actually useful in the context of a particularly "strong" credential 
format. 

However, I think that in order to get an interoperable protocol that 
allows one to meet the overall charter we'll probably have to mandate 
that overhead, since we certainly will have to pick some credential 
format, and I'd be very surprised if that format is likely to be safe 
to use without the additional overhead.

Bit fuzzy I know, but I hope you get what I mean. 

> corresponding functional requirements within the existing protocol

I'm not sure that that'd work very easily but am certainly willing to
consider it. I guess the reason for listing vulnerabilities (and I 
agree that whatever list we end up with will be non-exhaustive) was
that I think its easier to do this way for requirements (i.e. less
danger of inadvertently including design in the requirements draft). 

Note also that the current draft doesn't say "protocols MUST prevent..."
but rather that they "SHOULD offer protection" and MUST specify how they 
do, or don't, protect against the listed vulnerabilities. There wasn't
an intent to declare a protocol as not meeting the requirements just
because there's some vulnerability listed that the protocol doesn't 
absolutely prevent (as long as that's noted in the protocol specification). 
Maybe this needs to be clearer?

> types.  If so, this might be a worthwhile clarification to include.

Good point.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com