[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [TLS] SPNEGO over TLS - proposed new work item






I think, if work proceeds, there should be a parallel (minimal) effort, on a revised https spec. It should state that "https" cannot use - in a conforming manner - "external" authentication mechanisms of TLS.
 
Nothing stops anyone defining another http/x protocol that embraces external authentication techniques generally, or a specific external authentication technique such as offline kerberos. However, we need to keep the brand value of "https" clear - not necessarily allowing all features in TLS to be made available via the https moniker.



> From: martin.rex@xxxxxxx
> Subject: Re: [TLS] SPNEGO over TLS - proposed new work item
> To: stefans@xxxxxxxxxxxxx
> Date: Fri, 10 Nov 2006 20:40:19 +0100
> CC: jaltman@xxxxxxxxxxxxxxxxxxxx; tls@xxxxxxxx
>
> Stefan Santesson wrote:
> >
> > We had a design meeting today to conclude discussions about this proposal
> > that has surfaced during the IETF week.
> >
> > As such the proposal has changed in the way that SPNEGO has been removed
> > from the proposal and replaced with direct exchange of GSS-API tokens.
> > The slides for the presentation tomorrow has been sent to Eric and should
> > be up on the meeting materials page before the TLS meeting.
> >
> > A first draft will be available for consideration short after this IETF
> > and Jeff Altman has agreed to help as co-editor.
>
> A thought that came to me during todays tls meeting was the following:
>
> With exiting SSL/TLS (and -implementations), the authenticated peer
> becomes part of the SSL session state in the SSL session cache.
>
> When including an "external" authentication in the TLS handshake,
> what happens with the information about the authenicated peer,
> how is it "persistet", so that it will be transparently available
> when that SSL session is later resumed?
>
> Some features of existing GSS-API mechanisms (and future features,
> in particular about authorization attributes and subject alt name
> retrieval) might be extremely non-trivial to persist in the
> SSL session cache.
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxxxxxxxx
> https://www1.ietf.org/mailman/listinfo/tls



Use Messenger to talk to your IM friends, even those on Yahoo! Talk now!
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls