Subject: Further SACRED requirements comments

From: "Linn, John" <[email-masked]>
Date: Mon, 8 Jan 2001 12:48:34 -0500

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

---

From: Al Arsenault <[email-masked]>
Date: Mon, 8 Jan 2001 22:25:40 -0500

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:[email-masked]]
Sent:	Monday, January 08, 2001 12:49 PM
To:	[email-masked]'
Subject:	Further SACRED requirements comments

> 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 ". 
:-(

> 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?

> 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.

> 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.

> 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.

> --jl

Al Arsenault

---

From: "Linn, John" <[email-masked]>
Date: Tue, 9 Jan 2001 08:38:46 -0500

> be expected to process the credential at some point, or is 

I was trying to draw out the point that, while a credential format may be
opaque to the protocol per se, it still needs to be recognized and processed
within the end entities.  This may be stating the obvious, but (mindful also
of some discussion at the San Diego session about distinctions between
SACRED protocol requirements vs. end-entity requirements), I thought it
might be a clarifying point to add here.

> That's my .02, but we welcome comments from others on this issue.

I fully agree.  I think that the authenticity and integrity protection
spanning from credential generation to usage, at the level of the credential
object, is of primary importance (even though not strictly a part of the
SACRED protocol); applying the same services at the connection level offers
incremental value but doesn't replace the benefits of object-level
protection.  It seems like a classic end-to-end security argument; if it's
possible to abstract away trust in intermediaries, it's usually good to do
so. 

--jl

---

From: Al Arsenault <[email-masked]>
Date: Tue, 9 Jan 2001 14:34:50 -0500

John,

-----Original Message-----
From:	Linn, John [SMTP:[email-masked]]
Sent:	Tuesday, January 09, 2001 8:39 AM
To:	'Al Arsenault'; [email-masked]'
Subject:	RE: Further SACRED requirements comments

I was trying to draw out the point that, while a credential format may be
opaque to the protocol per se, it still needs to be recognized and 
processed
within the end entities.  This may be stating the obvious, but (mindful 
also
of some discussion at the San Diego session about distinctions between
SACRED protocol requirements vs. end-entity requirements), I thought it
might be a clarifying point to add here.

AWA:  I agree with you then, and we'll change the wording.  (Darn, I regret 
missing the San Diego meeting - sounds like the discussions were pretty 
productive. Okay, the beer in Munich was certainly substantially better, 
but other than that...)

		Al Arsenault