RE: Further SACRED requirements comments

[Al Arsenault <aarsenault@xxxxxxxxx>]

John,

	Thanks for your as-always-well-thought-out comments.  My responses 
in-line, prefaced by my initials, "AWA"..

-----Original Message-----
From:	Linn, John [SMTP:jlinn@xxxxxxxxxxxxxxx]
Sent:	Monday, January 08, 2001 12:49 PM
To:	'ietf-sacred@xxxxxxx'
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 
to
> "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 
the
> 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 
the
> 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
> conformance.
>

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.) 
 I'm
> 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 
the
> 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 
to
> place server authentication upon download as a general SHOULD, 
independent
> of whether or not that authentication occurs prior to the download
> operation?
>

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.


> --jl
>
>


Al Arsenault