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

[Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>]

Yes. The problem is, I guess, that one cannot assume that keys needed to
enable a server-side TLS authentication will be present at the client end.

-- Magnus

On Fri, 8 Dec 2000, Mike Just wrote:

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