[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Security Considerations
Ok, tho I think quite a few of us would argue that this decision will
likely not have any impact on the interoperability of the protocol, it
should allow us to start moving forward again...
Does this text meet the requirement:
The use of client authentication mechanisms to prevent posting or
editing by unknown or unauthorized clients is RECOMMENDED but not
required. When authentication is not used, clients and servers are
vulnerable to trivial spoofing, denial of service and defacement
attacks, however, in some contexts, this is an acceptable risk.
The type of authentication used is a local decision made by the server
operator. Accordingly, clients are likely to face authentication
schemes that vary across server deployments. At a minumum, clients
and servers MUST be capable of using HTTP Basic Authentication
[RFC2617] in conjunction with a TLS connection [RFC4346] as specified
by [RFC2818].
- James
Sam Hartman wrote:
>
> Hi folks.
>
> This has been a long discussion and has helped us all understand our
> various points of view, but I think we are no longer making forward
> progress.
>
> The IESG discussed this issue during the working group news section of
> today's telechat.
>
> The conclusion of those on the call is that in order to meet IETF
> interoperability requirements APP must normatively require a mandatory
> to implement security mechanism for HTTP authentication.
>
> Thanks again for helping us all understand this complex issue.
>
> There are a lot of related items that came out of this discussion. I
> don't think it would be appropriate to block APP. However if the
> right group of people want to get together and write a security
> current practices document for HTTP, that might be useful to future
> protocols in the same position as APP. That effort would need to be
> coordinated with several related HTTP efforts that are underway or
> being considered.
>
> Sam Hartman
> Security Area Director
>
>