Using the Secure Remote Password (SRP) Protocol for TLS Authentication
RFC 5054

Note: This ballot was opened for revision 14 and is now closed.

(Tim Polk) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Russ Housley) No Objection

Comment (2007-08-18)
No email
send info
  The discussion that followed the Gen-ART Review by Brian Carpenter
  indicates that the reader would be served by a minor change.  All of
  the details from [SRP-6] that are needed to implement are included in
  draft-ietf-tls-srp-14.  For this reason [SRP-6] is an informational
  reference.  This fact should be stated in the document at the first
  place that a reference is made to [SRP-6].

(Cullen Jennings) No Objection

(Dan Romascanu) No Objection

(David Ward) No Objection

(Chris Newman) Abstain

Comment (2007-07-24)
No email
send info
This is a weak abstain (I'm not asking other area directors to join my
position).  If the target were standards track, this would be a strong
abstain.

This a matter of application software architecture that applies to any
user-based authentication mechanism embedded in TLS that involves
or may involve unspecified server storage of per-user credential
information.

TLS stacks and the APIs to TLS stacks have started to ossify into
operating systems, mobile devices and shipping application software.
Such stacks are absolutely critical to application security, and are
already so complex that they are the cause of a significant number of
software defects and security updates.  I am very concerned about
adding unnecessary complexity to such a critical software component.
There is already a great deal of flux upgrading the cipher suites,
cipher modes and hash functions in these stacks.

Meanwhile, all the software infrastructure in applications surrounding
user identity, server credential repositories for users, and identity
federation is highly complex and in a great deal of flux.  If one looks
at the amount of complexity in the GSSAPI or deployed general
purpose SASL APIs and imagines the complexity of a software stack
including all those APIs blended with a TLS API, I find the prospect
daunting.  Indeed the complexity is sufficiently great that I consider
it bad architecture.

Meanwhile, there's a viable alternative.  If TLS and an authentication
framework such as GSSAPI, EAP or SASL are loosely bound using a
mechanism such as TLS channel bindings (TLS negotiates the security
layer which is subsequently bound to a completely separate user
authentication), then there is a very simple and clean boundary
between the two software stacks, leading to a much more pragmatic
real-world architecture.