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

From: Mike Just <[email-masked]>
Date: Mon, 9 Apr 2001 09:57:28 -0400

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:[email-masked]]
> Sent: Saturday, April 07, 2001 6:41 AM
> To: [email-masked]
> 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
> [email-masked]
> http://www.cs.hmc.edu/~awooster
>