Changeset 2399
- Timestamp:
- 15/09/13 00:56:07 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p7-auth.html
r2398 r2399 937 937 </p> 938 938 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="auth.credentials.and.idle.clients" href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></h2> 939 <p id="rfc.section.6.1.p.1">Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1 does not provide 940 a method for a server to direct clients to discard these cached credentials. This is a significant defect that requires further 941 extensions to HTTP. Circumstances under which credential caching can interfere with the application's security model include 942 but are not limited to: 939 <p id="rfc.section.6.1.p.1">Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP does not provide a mechanism 940 for the origin server to direct clients to discard these cached credentials, since the protocol has no awareness of how credentials 941 are obtained or managed by the user agent. The mechanisms for expiring or revoking credentials can be specified as part of 942 an authentication scheme definition. 943 </p> 944 <p id="rfc.section.6.1.p.2">Circumstances under which credential caching can interfere with the application's security model include but are not limited 945 to: 943 946 </p> 944 947 <ul> … … 950 953 </li> 951 954 </ul> 952 <p id="rfc.section.6.1.p.2">This is currently under separate study. There are a number of work-arounds to parts of this problem, and we encourage the 953 use of password protection in screen savers, idle time-outs, and other methods that mitigate the security problems inherent 954 in this problem. In particular, user agents that cache credentials are encouraged to provide a readily accessible mechanism 955 for discarding cached credentials under user control. 955 <p id="rfc.section.6.1.p.3">User agents that cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials 956 under user control. 956 957 </p> 957 958 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="protection.spaces" href="#protection.spaces">Protection Spaces</a></h2> -
draft-ietf-httpbis/latest/p7-auth.xml
r2398 r2399 689 689 <t> 690 690 Existing HTTP clients and user agents typically retain authentication 691 information indefinitely. HTTP/1.1 does not provide a method for a 692 server to direct clients to discard these cached credentials. This is 693 a significant defect that requires further extensions to HTTP. 691 information indefinitely. HTTP does not provide a mechanism for the 692 origin server to direct clients to discard these cached credentials, since 693 the protocol has no awareness of how credentials are obtained or managed 694 by the user agent. The mechanisms for expiring or revoking credentials can 695 be specified as part of an authentication scheme definition. 696 </t> 697 <t> 694 698 Circumstances under which credential caching can interfere with the 695 699 application's security model include but are not limited to: … … 706 710 </t> 707 711 <t> 708 This is currently under separate study. There are a number of work-arounds 709 to parts of this problem, and we encourage the use of 710 password protection in screen savers, idle time-outs, and other 711 methods that mitigate the security problems inherent in this 712 problem. In particular, user agents that cache credentials are 713 encouraged to provide a readily accessible mechanism for discarding 714 cached credentials under user control. 712 User agents that cache credentials are encouraged to provide a readily 713 accessible mechanism for discarding cached credentials under user control. 715 714 </t> 716 715 </section>
Note: See TracChangeset
for help on using the changeset viewer.