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

[Al Arsenault <awa1@xxxxxxxx>]

John,

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

"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.
 
> 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.)
 
> --jl
> 
> 


			Al Arsenault
			Chief Security Architect
			Diversinet Corp.