Re: I-D ACTION:draft-ietf-sacred-framework-01.txt

[Dale Gustafson <dale.gustafson@xxxxxxxx>]

Hi Andrew,

Comments inline.

Best Regards,

Dale Gustafson

Andrew Wooster wrote:

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

SACRED is protocol 1.  The picture is shown to explain the larger context in
which 1 is operating.  Also to note that 2 and 3 are out of scope but related to
1.

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

Probably not.

Several people have, at one time or another, expressed interest in / would like
to ensure that clients can update (upload) secured credentials directly to a
credential store.  Others have indicated there may be a need to download
credentials directly from the credential store.  The comment above is merely to
acknowledge that direct exchanges with a credential store are also possible.

> Thanks,
>
> -Andrew Wooster
> awooster@xxxxxxxxxx
> http://www.cs.hmc.edu/~awooster