RE: Further SACRED requirements comments
Al Arsenault <aarsenault <at> dvnet.com>
2001-01-09 03:25:40 GMT
Thanks for your as-always-well-thought-out comments. My responses
in-line, prefaced by my initials, "AWA"..
From: Linn, John [SMTP:jlinn <at> rsasecurity.com]
Sent: Monday, January 08, 2001 12:49 PM
To: 'ietf-sacred <at> imc.org'
Subject: Further SACRED requirements comments
> I'd like to offer a few further comments about the SACRED requirements
> document, over and beyond those raised in prior list discussion and noted
> in the San Diego discussion minutes.
> Regarding treatment of the serverless case, it seems (a) that it's
> suitably motivated within the requirements document but (b) that there's
> not as much current momentum or constituency to carry it forward into
> lower-level documents. If this situation persists, I suggest keeping the
> requirements-level discussion as is but narrowing the framework scope to
> "Securely Available Credentials - Framework with Credential Servers" or
> some such. This would allow the serverless case to be pursued in a
> parallel framework document at a later date.
AWA: I think that that's a reasonable approach. If I get time, I'm going
to start pushing harder on the serverless case, since that's the one of
most direct importance to me, but these days "if I get time" equates
roughly to "if the Sahara Desert or other very warm place freezes over ".
> In the requirements document, #F4 might usefully be restated "The details
> of the actual credential type or format MUST be opaque to the protocol,
> though not to processing within the protocol's peers. The protocol MUST
> NOT depend on the internal structure of any credential type or format."
AWA: Okay, I'm not exactly sure what you mean by the new clause "...though
not to processing within the protocol's peers..." Is your intent to convey
that the entities that execute the SCACRE protocol in question might also
be expected to process the credential at some point, or is there some other
point that I'm missing?
> If #G3 and #G4 (authentication and integrity protection for transferred
> credential data) are necessarily to be accomplished by the protocol,
> rather than within the credential objects themselves, suggest rewording
> "The protocol <SHOULD|MUST> provide ...", consistent with subsequent
> requirements. More broadly, just what does it mean to authenticate a
> credential, vs. authenticating a protocol peer? In the case of a
> download, e.g., the originator of the credential may well have signed the
> credential object at some point in the past, enabling its authenticity to
> be verified, but won't generally be its source from the perspective of
> transfer protocol. Does the original object signing satisfy the intended
> requirement, or is this intended to concern connection-level
> authentication of the credential provider (e.g., via TLS)?
AWA: Well, my intent was that the actual credential itself SHOULD/MUST
have been (signed/MACed/...), and that e.g. signature on the original
object meets these requirements. These were not intended to be
requirements that the entities executing the protocol provide such
protection for the credential while in transit. Why, you might ask?
Because to me it seems more important that the original object be protected
from original "creation" point until delivered to the user than merely
protected in transit. E.g., the fact that a key was transferred over a TLS
session is nice, but it doesn't say anything about what happened to that
key PRIOR to the fact of it being transferred, while imposing the
requirements on the original object does say something powerful.
That's my .02, but we welcome comments from others on this issue.
> Re #G7, it seems somewhat strange to specify support for a particular
> credential format (an opaque object transported by the protocol) under
> heading of a protocol conformance requirement; by analogy, it would be as
> if conformance to the TCP specification required support for HTTP (or for
> any other specific protocol which layers over TCP). This may be an
> interoperability requirement, but it seems outside the scope of protocol
AWA: G6 and G7 really go together on this. I'll look around and see if
there's a better place to put those two requirements. I'd sort of like to
leave them in the document somewhere, though.
> Requirements #S6 and #S7 mesh a bit oddly to me. I can see value in
> authenticating the server to the client for download, primarily as an aid
> to determining that the most current version of a credential is being
> obtained. (I'd expect that a wholly invalid credential would probably be
> detected based on integrity facilities within the credential format.)
> not sure that this is necessarily a MUST for all cases, but don't think
> that its value depends on whether or not the server authentication can be
> verified before the credential crosses the wire. If, e.g., a
> correctly-formed credential carried data which could be used as one of
> inputs applied to cross-check the server's authenticity after the fact,
> this could be OK (as long as the client didn't overwrite any existing
> credentials before these steps were performed). Would it be reasonable
> place server authentication upon download as a general SHOULD,
> of whether or not that authentication occurs prior to the download
AWA: I can live with that suggestion. It's sort of interesting now that I
look at it again that we say "... MUST... if the user is able to verify..."
I think a SHOULD would be okay, here.