Hi Andrew,
Depending on how the eventual protocol 1 is designed, the secured credentials may be posted to the credential store either through path 2 or path 3. We only mention them once to indicate this option. The "SACRED protocol" really consists of protocol 1, hence the remainder of the draft is dedicated to discussion of only this protocol. (I suppose that there would have to be some guidance regarding the use of protocol 3 though.)
For example, supposing that the credential server provides the client with a symmetric key with which the client may encrypt their credentials, then the client may post the result to the credential store without the aid of the credential server. Alternatively, the client may submit their credentials to the credential server (e.g. over a TLS session), who subsequently might encrypt with a symmetric key K, and post the result to the credential store. (Note that the credentials submitted to the server would likely already be protected with Pass Key generated from the client's password.)
As you indicate below, the server can certainly uses whatever "protocol 2" they choose. I don't see SACRED specifying this. Using protocol 3 has advantages in that it can allow some decreased load for the credential server; this would be one of the reasons we didn't want to exclude this option.
Mike
> -----Original Message-----
> From: Andrew Wooster [mailto:wooster@xxxxxxxxxxxxx]
> Sent: Saturday, April 07, 2001 6:41 AM
> To: ietf-sacred@xxxxxxx
> Subject: Re: I-D ACTION:draft-ietf-sacred-framework-01.txt
>
>
> Maybe I'm missing something here, but why is it specified in
> draft-ietf-sacred-framework-01 (section 2.3) that:
>
> "Clients are not precluded from exchanging credentials directly
> with a credential store (or any other server of it's choosing)."
>
> This corresponds to protocol 3 in the chart given:
>
> +--------+ +------------+
> | Client +-----------| Credential |
> +--------+ 1 | Server |
> \ +-----+------+
> \ |
> \ | 2
> \ |
> \ 3 +-----+------+
> -----------| Credential |
> | Store(s) |
> +------------+
>
> I believe this chart was designed by Stephen Farrell and given in
> http://www.imc.org/ietf-sacred/mail-archive/msg00005.html.
>
> I'm not entirely certain where protocols 2 and 3 fit in with the rest
> of sacred. Section 2.3 appears to be the only section to mention them.
>
> Also, because the frameworks document specifies (as does the
> requirements
> document) that sacred support multiple authentication schemes, the
> suggestions for using LDAP/SSL over protocol 3 above don't seem
> relevant.
>
> So, my basic questions are: Why are 2 and 3 described in the
> frameworks
> draft? Is there an inherent need to cover an additional transfer
> mechanism over protocol 3 that wouldn't be better served by
> encapsulating
> credential transfer in protocol 1? If the credential server wishes to
> retrieve and store credentials from some arbitrary credential
> store using
> an implementation-specific protocol, should sacred care?
>
> Thanks,
>
> -Andrew Wooster
> awooster@xxxxxxxxxx
> http://www.cs.hmc.edu/~awooster
>