Unless I'm overlooking something, this seems to imply that for the initial authentication request from the client, either we're not doing server authentication (since there are no trusted keys to perform server auth with TLS), which I think is a bad idea, or we are performing server authentication, and we're doing it using a strong password based protocol. I'm not saying this is bad. It just seems to be an implication of your statement.
Mike J.
> -----Original Message-----
> From: Magnus Nystrom [mailto:magnus@xxxxxxxxxxxxxxx]
> Sent: Friday, December 08, 2000 10:04 AM
> To: Linn, John
> Cc: ietf-sacred@xxxxxxx
> Subject: RE: I-D ACTION:draft-ietf-sacred-framework-00.txt
>
>
> The intent is to include trusted public keys in the credential
> and not to assume they already are available.
>
> -- Magnus
>
> On Fri, 1 Dec 2000, Linn, John wrote:
>
> > Mike wrote, excerpting:
> >
> > > [...]
> > > > > - [Section 3.1, 2nd bullet] The requirement for http
> might be ok, but
> > why
> > > > > require TLS. This gets into the argument that you
> mention in Section
> > 6,
> > > > > regarding the (de)coupling of the credential and
> protocol protections.
> > The
> > > > > strong password algorithms of Section 4.2 would not
> require TLS
> > protection,
> > > > > for example.
> > > >
> > > > In this draft, we removed a few restrictions that had
> been suggested
> > earlier --
> > > > originally HTTP over TLS was the only transport
> considered and was
> > mandantory.
> > > > In this revision HTTP / TLS is not the only possible
> transport protocol.
> > We may
> > > > have to refine the wording in several additional places
> to makethis more
> > clear.
> > >
> > > Note also that it only says "must be able to..." - it does not
> > > require TLS. I agree that the memo requires some clarification in
> > > this respect however, e.g. Section 3.1.1, first item in the list
> > > should probably read something like "..., that is, when
> TLS is used,
> > > only cipher suites..."
> > >
> >
> > [MJ] I guess that "requiring" and "being able to" aren't
> that different to
> > me. Your rewording sounds fine in any case.
> >
> > I take the intent as requiring support for TLS in the interests of
> > interoperability, though without mandating that it must
> always be active and
> > used. More broadly, though, I believe that there's a
> dependency that
> > warrants some explicit discussion. In order to validate
> TLS server-side
> > authentication, it's necessary for the verifier to hold a
> corresponding
> > trusted public key. Strong password schemes, in contrast,
> may not incur this
> > dependency in order to establish a trusted channel to a
> server and therefore
> > could enable an entity's trusted keys to be provisioned
> across that channel.
> >
> >
> > Does/should the scope of credential download include
> transfer of an entity's
> > trusted public key(s), or do we assume that they're already
> available as a
> > basis for authenticating credential servers in the course
> of obtaining
> > credentials? The first paragraph of draft-ietf-sacred-reqs-00.txt's
> > Introduction refers to trusted roots as one element within
> credentials
> > themselves, but I'm unsure where we currently stand on this
> question.
> >
> > --jl
> >
> >
>
> -- Magnus
> Magnus Nystrom
> RSA Security
>
>