Subject: coments on draft-ietf-sacred-protocol-bss-00

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 11 Dec 2001 17:29:37 -0700

I was reading over the latest draft last night 
(draft-ietf-sacred-protocol-bss-00.txt) and I have a few questions on 
things that confused me.

Section 2.1.2 introduces the "Create Account" operation.  It doesn't have 
any mention of a server wishing to only store credentials for authorized 
users or any way that a server might wish to authenticate a user before 
creating an account for them.  (For instance, a server might require 
authentication using a different SASL mechanism before allowing a user to 
create an account.)

Or a site with a preexisting authentication infrastructure might already 
have SRP authenticators to use, and there's no need for a user to upload a 
new SRP authenticator.

Thus, I think account management should be in a seperate section from the 
credential upload/download, and should be an optional part of the server to 
implement.  A baseline SACRED client/server has to support upload/download 
(that's the point) but not necessarily the account management.

Section 2.2: authorization identity must equal authentication identity. 
Why is there this restriction?  A client should be able to attempt to 
authorize as some other user; it's a server's site policy that determines 
whether or not this is allowed.  The easiest site policy is to always 
disallow proxying.

(Also, SASL allows a client to send the empty authorization string to 
"derive authorization from authentication credentials".)

Section 2.2: The mandatory to implement TLS cipher-suite appears to also be 
the the only one allowed:

   The mandatory-to-implement TLS cipher-suite for sacred is:
   TLS_RSA_WITH_3DES_EDE_CBC_SHA. This MUST be used for both sTLS and
   cTLS cases.

Is this really what's intended?  Shouldn't a client and a server be allowed 
to use other cipher suites, as long as both support 
TLS_RSA_WITH_3DES_EDE_CBC_SHA so interoperability is guaranteed?

Section 2.3: why only one operation per connection?  I suggest instead that 
clients MUST be prepared to deal with servers that close the connection 
after a single operation and servers SHOULD support multiple commands per 
connection.  To simplify, you might want to say that commands MUST NOT be 
pipelined; the result of a previous command must be received before the 
next command can be sent.

Section 4.3: There should probably be error codes for "over quota" or other 
administrator limitations.

Appendix C: administrator operations: I don't see an overwhelming need to 
interoperate with administrative operations.  If there's a desire for this, 
further messages can be defined later.

Appendix C: mapping from SASL-SRP id to cTLS certificate: this is a very 
hard problem and is out of scope for SACRED.

References: There are many normative references to works in progress such 
as XKMS and XBULK. Is the working group concerned that there might be a 
long wait for publication?  Is xkms sufficiently far along?

[Bob Morgan shares credit for any of the insightful comments above.]

thanks,
Larry

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Dec 2001 23:51:45 +0000

Hi Lawrence,

> (that's the point) but not necessarily the account management.

Sounds like a good idea. I'll include that next time 'round.

> whether or not this is allowed.  The easiest site policy is to always

It seemed simpler. Is there really a need for separate identities 
for sacred? I wouldn't have thought so.

> "derive authorization from authentication credentials".)

Maybe that's a better way to do what I was trying to do.

> TLS_RSA_WITH_3DES_EDE_CBC_SHA so interoperability is guaranteed?

Why do you want to use other ciphersuites? (I mean now, as opposed to at
some future date.)

> Section 2.3: why only one operation per connection?  

Simplicity.

> I suggest instead that

Sounds hard to do, for little benefit. How often will multiple sacred
operations be needed?

> administrator limitations.

Fair enough. Care to suggest text?

> further messages can be defined later.

Sounds right. If no-one else wants them they'll go.

> hard problem and is out of scope for SACRED.

People seem to think that all right. I need to think about it. (But note 
that we're not trying to solve the problem in general, just in the case
of sacred.)

> long wait for publication?  Is xkms sufficiently far along?

Are we? :-)

I don't think this is a problem since we'd only be using small bits
of either and could cut&paste at worst.

Cheers,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Magnus Nystrom <[email-masked]>
Date: Thu, 13 Dec 2001 01:20:07 +0100 (MET)

Stephen,

On Wed, 12 Dec 2001, Stephen Farrell wrote:

[...]
> for sacred? I wouldn't have thought so.

To me, it seems un-necessary to have this constraint. Clients that do
not wish to make use of it, or servers that don't want to honor it are
still free to do so. In short, I support Lawrence's suggestion.  This
is also the approach we took in our recent posting.

[...]
> > pipelined; the result of a previous command must be received before
> > the next command can be sent.
>

Actually, this may be a no-op depending on the degree that the
suggestions made by me and Gareth are accepted; in our proposal, there
would be a persistent connection until it explicitly is closed. And
commands would not be allowed to be pipelined, as Lawrence suggests.
Speaking of that proposal, Gareth and I will try to highlight
suggestions we have (apart from the already discussed BEEP and SASL
issue) in a separate thread, since we feel they haven't received much
attention yet.

[...]

-- Magnus

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Dec 2001 16:22:01 +0000

Explain to me why I need separate authentication and
authorization (sasl) identities for sacred? 

If its not needed for sacred, IMHO, it shouldn't be in.

We did have some calls that we aim for simplicity
at the meeting.

Stephen.

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 13 Dec 2001 11:32:01 -0500

Date: Thu, 13 Dec 2001 16:22:01 +0000
   From: Stephen Farrell <[email-masked]>
   Organization: Baltimore Technologies Ltd.
   CC: Lawrence Greenfield <[email-masked]>, [email-masked]

Disallowing this is nonsensical.  Server implementors can disallow it
if they don't want.  It's a standard SASL feature.  I use it regularly
to debug problems for users (authenticate as an administrator,
authorize as a user).

This doesn't increase complexity; neither clients nor servers have to
implement it and it doesn't harm interoperability.  SACRED would be
the only protocol with this restriction, hurting code reuse.

Larry

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Dec 2001 16:57:20 +0000

Larry,

So, there's no specific use for this in sacred, other than
debugging? 

Stephen.

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 13 Dec 2001 09:14:53 -0800 (PST)

> Explain to me why I need separate authentication and authorization
> (sasl) identities for sacred?
>

Typical scenarios for other protocols that use authorization ID are
administrator access and proxy/middle-tier access.  I can imagine a setup
where it's useful for a sysadmin to have the ability to do upload/download
operations "as the user" as part of problem determination.  I can also
imagine setups using proxy frontends to deal with different authentication
capabilities in clients.  Just because some folks wouldn't use them
doesn't mean these scenarios should be forbidden.

RFC 2222 says that a protocol defining its use of SASL has to provide:

   5. A specification of how the authorization identity passed from the
      client to the server is to be interpreted.

So I think the point is to permit implementations to do useful things with
this without making it a burden for those that don't want to use it.
Here's language that I think does that, replacing current language in 2.2
of draft-ietf-sacred-protocol-bss-00.txt:

  Implementations MAY support the use of the SASL authorization identity
  field.  If present, the field is interpreted in an
  implementation-specific manner to select a particular account, subject
  to authorization controls applied by the server.  An unrecognized or
  inappropriate authorization identity MUST cause the server to respond
  with a 537 error code.

I will also point out that handling this as an error is an example of the
additional things that have to be reinvented at the application level if
the unwise course of defining SASL in this protocol is pursued.  Using
BEEP gives you language about handling authorization ID and error codes
for free.

 - RL "Bob"

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Dec 2001 17:30:40 +0000

Bob,

> administrator access and proxy/middle-tier access.  

Do we have such requirements? Where in 3157 is that mentioned?

> Just because some folks wouldn't use them

I'm in "if its not needed, leave it out" mode at the moment:-)

> [...] an example of the

Feel free to comment on that in the separate thread "sasl in beep 
or payload",

Stephen.

---

From: Magnus Nystrom <[email-masked]>
Date: Thu, 13 Dec 2001 10:30:18 -0700 (Mountain Standard Time)

I agree with Bob on the use of authorization identities. I can also
see other usages for these, e.g. a common set of role-based
credentials which may be accessed when authenticating as belonging to
a certain set of users.

Regarding error codes, I really don't want to continue that thread,
but I can't help noting that the current protocol I-D defines new BEEP
error codes to cater for SACRED specific errors.

-- Magnus

> BEEP gives you language about handling authorization ID and error codes

-- Magnus
Magnus Nystrom
RSA Security

---

From: "Marshall Rose" <[email-masked]>
Date: Thu, 13 Dec 2001 23:52:23 -0800

> error codes to cater for SACRED specific errors.

hi. i don't think you understand section 8 of the beep spec.

the list of reply codes given isn't an exhaustive list of reply codes that
can occur in an "error" element.

rather, it's a list of codes that the working group agreed on for common
use. for example, you'll see those reply codes (and others) in
implementations of channel 0, some of the sal profiles, the tls profile etc.

if you look at some other profiles that use beep, you'll see that some of
them choose to use the "error" element defined in beep. some don't.

those that do, use the same list or may add some codes.

so, thinking that section 8 is some kind of a totality is wrong.

now, it turns out that there is an issue with the new reply codes defined in
the sacred spec. specifically, rfc 821, which defines "the theory of reply
codes" talks about the significance of the 'x', 'y', and 'z' digits that you
find in a reply code, and the codes that sacred defines, doesn't fit into
that taxonomy. when i get home and can consult 821 in a quiet room, i'll
send a note suggesting what the actual xyz values should be...

/mtr

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 13 Dec 2001 16:03:55 -0800 (PST)

On Thu, 13 Dec 2001, Stephen Farrell wrote:

> ...

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.

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

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.

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

---

From: "David Chizmadia" <[email-masked]>
Date: Fri, 14 Dec 2001 22:35:04 -0500

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

> that I'm familiar with, and it seems to me people would want them with

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!

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

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

> supports the scenarios I'm interested in, and is consistent with most

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

---

From: "Marshall T. Rose" <[email-masked]>
Date: Sat, 15 Dec 2001 00:28:34 -0800

here are my comments, mostly editorial. (obviously, if the group has
consensus for http, we can ignore the beep related comments.)

*** section 1, 2nd paragraph:
>    The security of the protocol is based on [SRP]. The protocol uses
>    [BEEP] as its transport layer and the [SASL] SRP mechanism [SASL-
>    SRP] to encapsulate the SRP exchanges. The payloads consist of a set
>    of XML messages defined here. The protocol sets out to meet the
>    requirements in [REQS].

beep isn't a transport layer, so either:

    s/as its transport layer/for its exchange model/

    s/transport layer/session layer/

*** section 2, sections 2.1.1-2.1.6

it would be a lot easier if there were three paragraphs in each of these six
sessions.

    - the first paragraph says "The purpose of this operation is..."

    - the second paragragh says "The X sends the A ... The Y sends the B
..."

    - the third paragraph says "This operations requires XXX security"

*** section 2.1, editorial remark regarding "tuned"

the term "tuned" is a term of art in beep. typically, sessions are "tuned
for security" (a generic expression) or "tuned for privacy" or "tuned for
authentication" (both more specific expressions).

you can probably replace the editorial remark with an example of a session
being tuned, e.g., one of the examples from section 3 of rfc 3081.
alternatively, if you'd like to show an example of SRP, scroll down to the
end of the message, and i've put in an example:

*** Section 2.2:

>    Where there is a choice (e.g. Remove account), servers MUST support
>    both options and clients MUST support at least one of the options.

s/Remove account/either SRP or cTLS/

*** Section 4.1

the URIs used to start the profile are inconsistent with the one defined at
the beginning of section 4.

*** Section 4.3

>    code  meaning
>    ====  =======
>    777   Extension (ProcessInfo) used not supported
>    778   Required extension (ProcessInfo) not present

appendix e of rfc 821 introduced the "theory of reply codes", which has
modestly evolved since 1981. a reply code is a three-digit number. the first
digit is 1-5 and indicates success/failure,
permanent/transient/intermediate. the third digit is 0-9 and is an
instance-identifier. the second digit is interpreted as:
syntax (0), informational(1), connection(2), security(3),
application-specific(5).

since these two codes reflect a permanent error, the first digit should be
5. since they reflect application-specific requirements, the second digit
should be 5. the third digit can be something that isn't already used.

*** Section 5, IANA Considerations

here are two new open questions:

1. should we apply for a port number?
2. should we define a url scheme?

*** Appendices A & B

it would be nice if this material was consistently indented, capitalized,
etc., to make it easier to read...

/mtr

ps: here is what tuning for authentication and privacy looks like using SASL
SRP:

#######

    L: <wait for incoming connection>
    I: <open connection>
    L: RPY 0 0 . 0 170
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile uri='http://iana.org/beep/TLS' />
    L:    <profile uri='http://iana.org/beep/SASL/SRP-SHA-160' />
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 52
    I: Content-Type: application/beep+xml
    I:
    I: <greeting />
    I: END
    I: MSG 0 1 . 52 184
    I: Content-Type: application/beep+xml
    I:
    I: <start number='1'>
    I:    <profile uri='http://iana.org/beep/SASL/SRP-SHA-160'>
    I:        <![CDATA[<blob>...</blob>]]>
    I:    </profile>
    I: </start>
    I: END
    L: RPY 0 1 . 170 783
    L: Content-Type: application/beep+xml
    L:
    L: <profile uri='http://iana.org/beep/SASL/SRP-SHA-160'>
    L:     <![CDATA[<blob>...</blob>]]>
    L: </profile>
    L: END
    I: MSG 1 0 . 0 559
    I: Content-Type: application/beep+xml
    I:
    I: <blob>...</blob>
    I: END
    L: RPY 1 0 . 0 429
    L: Content-Type: application/beep+xml
    L:
    L: <blob>...</blob>
    L: END
    I: MSG 1 1 . 559 82
    I: Content-Type: application/beep+xml
    I:
    I: <blob>...</blob>
    I: END
    L: RPY 1 2 . 429 66
    L: Content-Type: application/beep+xml
    L:
    L: <blob status='complete' />
    L: END

        ... successful transport security negotiation ...

    L: RPY 0 0 . 0 127
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile uri='http://iana.org/beep/transient/sacred/bss' />
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 52
    I: Content-Type: application/beep+xml
    I:
    I: <greeting />
    I: END

#######

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Dec 2001 14:43:11 +0000

Thanks Marshall, I'll incorporate those.

Stephen.