[standards-jig] A few thoughts on JEP 0035
paul_lloyd at hp.com
Wed Jul 10 17:34:28 UTC 2002
Robert Norris wrote:
> > 2) <whiny> Would it make more sense to choose a namespace identifier other
> > than the reference to RFC2595? </whiny>
> The namespace identifier is completely up for grabs - that was the only
> thing I could think of that was even remotely relevant. Suggestions?
> > 3) Section 3 is a great companion to the use of SASL presented in JEP 0034.
> > To make the protocol specification complete, I think some statement needs
> > to be made about the use of the CertificateRequest message:
> > o is it, as in "vanilla" TLS, strictly a matter of server choice?
> > o or, is there some way for the client to indicate a preference for
> > TLS based authn in advance?
> > I'm fairly neutral, though eager to see this important feature of TLS used.
> I don't quite understand what you mean, though I'll freely admit that my
> understanding of TLS is not particularly good. As far as I understand it
> though, the server says "I support these client certificates", to which
> the client can choose to offer a certificate or not. If the offered
> certificate matches, then the SASL EXTERNAL mechanism is offered, which
> the client may select if it wishes.
> If I've misunderstood the way this works, please let me know - I'm still
> new to this.
Your understanding of the TLS protocol seems correct.
The only possibly interesting point to consider here is this: can clients
participate at all in the negotiation of authn methods besides simply
choosing from a list supplied by the server?
If the answer is no, then we're done.
If the answer is yes, then there is an issue. Although one can easily construct
an application protocol that features such negotiation, leveraging
credentials supplied and validated at a lower layer, like TLS, can
be awkward if the lower layer protocol does not support such negotiation.
In the case of TLS, one possible approach is for the application protocol
to specificy that compliant servers MUST request a cert and to specify that
compliant clients MAY respond with no cert. Then, once the TLS session is in
place, the client and server can perform their application layer authn however
As I mentioned originally, I don't have a strong preference.
> > 4) For completeness, are any statements needed about the circumstances
> > in which the client and server can resume an existing session during
> > the handshake? Should this simply be one of those "local matters"?
> For the sake of simplicity, I'd imagine we'd simply allow one session
> per connection, as we do now.
This makes sense for each TCP connection.
I also suspect you feel that session reuse across different TCP connections
should be left as a local matter. For example, if one constructs a client
with a toolkit that has a robust session cache, it may choose to attempt
reuse. If the server was built with a similar toolkit, then no problem; if the
server's toolkit doesn't cache sessions, then still no problem, because they
can simply negotiate a new session.
> > 5) For completeness, are any statements needed about the circumstances
> > in which the client side might want to send a new ClientHello message and
> > renegotiate the session's security parameters on the fly? Should this also
> > simply be one of those "local matters"?
> Again, for simplicity, I'd say that once the stream is established then
> thats the way it stays until disconnect.
On a related completeness note, what should we do about graceful termination?
In particular, after the Alert(close_notify) messages have been exchanged,
what is the state of the Jabber <stream:stream>s? Is there one?
Infrastructure Strategic Engineering
Strategy and Architecture Leadership Team
MSN Messenger: paul_lloyd at hp.com
paul_lloyd at hp.com
More information about the Standards