On Feb 23, 2006, at 11:19 AM, James M Snell wrote:
Alternative approach to PaceBasicAuthentication and
PaceAuthentication.
http://www.intertwingly.net/wiki/pie/PaceFixSecurityConsiderations
I am generally positive on this approach.
- APP is fairly late to the party of content creation via HTTP, and
*very* late to the party of securing HTTP transactions.
- Furthermore there are many in the IETF who hold passionate opinions
about the right and wrong way to secure net transactions in general
and HTTP in particular, and I would be happier if they didn't use the
APP draft as a place to continue the task of working through these
issues.
- Finally, without a deep technical understanding of these issues,
but having had considerable experience with security-admin and
security-architect types, I suspect that our specification has
relatively little chance of influencing their actions.
So I generally think that we win by saying the least possible that we
can get away with. -Tim
#pragma section-numbers off
== Abstract ==
Remove section 13. Replace section 14 with a more generic statement
about APP being subject to the same security considerations as RFC2616
with a constraint that if Basic Auth is used, TLS SHOULD also be used.
== Status ==
Proposed
== Rationale ==
APP is an HTTP spec. HTTP already has defined authentication
mechanisms. There is no need for APP to specify specific
authentication
mechanisms. CGI authentication is valuable, but best done as a
separate
spec deriving from RFC2617.
== Proposal ==
Remove section 13. Replace section 14.
{{{
14. Security Considerations
Implementations of the Atom Publishing Protocol SHOULD be protected
using
HTTP Authentication mechanisms as defined by or derived from
[RFC2617]. If
implementations choose to implement support for HTTP Basic
Authentication,
they SHOULD support encryption of the session using TLS [RFC2246]. The
security of the Atom Publishing Protocol is subject to the same
security
considerations as discussed in [RFC2616] and are entirely dependent
on the
strengths and weaknesses of the implementation and chosen
authentication
and
transport security mechanisms.
}}}
== Impacts ==
== Notes ==
----
CategoryProposals