Re: authorization IDs in SACRED

From: "RL 'Bob' Morgan" <[email protected]>

> I do apologize for not having paid enough attention to the requirements
> process to make this requirement clear.  I can only reiterate that these
> use cases show up in almost all modern application protocol deployments
> that I'm familiar with, and it seems to me people would want them with
> SACRED deployments.

I for one would definitely NOT want these cases to show up. My interest in
SACred is based on the fact that its requirements document lays out a very
straightforward bootstrap protocol that allows the use of a password,
possibly with username and/or creds-handle, to retrieve the credentials that
will be used for more complex authentication and authorization. Thus, the
protocol that I, as a security architect, want really only has a single Use
Case actor - the user proxy on an arbitrary device - with the Credential
server being an engineering simplification. There is ABSOLUTELY no need for
SACred to accommodate proxies and delegation. In my mind - and according to
RFC3157 - this would be equivalent to supporting such capabilities in a
personal identity Smartcard!

> It seems unreasonable to suggest that every possible use of the protocol
> that isn't defined in 3157 has to be prohibited.

As a long time security requirements and evaluation person, this stikes me
as a truly dangerous suggestion. While it is common practice among engineers
to use available technologies that are "almost" what they need when there is
no "exact fit" technology available, it is not the job of the available
technology designer to anticipate out-of-scope use. Rather, the designer
should carefully document in-scope use so that competent engineers
considering using it out-of-scope know exactly how far out of scope they
will be. I consider RFC3157 to be the definition of what is in scope for
SACred and believe that the protocol(s) that it spawns should be strict
subsets of the requirements listed. But of course, mine is only one voice.
:-)

> I think there are these choices (assuming that we're going to continue to
> use SASL in the protocol):
>
>  (1)  Leave out any mention of authorization ID.  This would be easiest
> for the document authors, but doesn't meet the requirements of RFC 2222
> and leaves implementors to wonder.
>
>  (2)  Require the authorization ID field to be empty.  This would be easy
> enough, but rule out any of the uses I and others have been advocating.
> It would also probably require lots of justification to non-WG folks
> reading the spec, including IESG, because it's different from any previous
> profile of SASL.  So in terms of getting the spec through I suggest it
> would slow things down, not speed them up.
>
>  (3)  Say that use of the field is undefined in this document.  This
> wouldn't rule out future use of the field, wouldn't require any further
> discussion in the document, but might be confusing to implementors.

I'm still trying to understand SASL and its use in SACred, but this
suggestion feels most comfortable. It seems that wording to the effect "The
use of the authorization ID field is undefined in this version of the SACRED
protocol; therefore, implementations SHOULD always behave as though it is
empty" has the advantages cited and provides unambiguous implementation
guidance.

>  (4)  Text like that I proposed in my previous message, which wouldn't
> require any more work from implementors that don't want to support it,
> supports the scenarios I'm interested in, and is consistent with most
> other SASL profiles.
>
>  - RL "Bob"

-DMC
David Chizmadia
Senior Software Security Architect
Promia, Inc
[email protected]