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


Reply via email to