分享
 
 
 

RFC2245 - Anonymous SASL Mechanism

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group C. Newman

Request for Comments: 2245 Innosoft

Category: Standards Track November 1997

Anonymous SASL Mechanism

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1997). All Rights Reserved.

Abstract

It is common practice on the Internet to permit anonymous Access to

various services. Traditionally, this has been done with a plain

text passWord mechanism using "anonymous" as the user name and

optional trace information, sUCh as an email address, as the

password. As plaintext login commands are not permitted in new IETF

protocols, a new way to provide anonymous login is needed within the

context of the SASL [SASL] framework.

1. Conventions Used in this Document

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"

in this document are to be interpreted as defined in "Key words for

use in RFCs to Indicate Requirement Levels" [KEYWORDS].

2. Anonymous SASL mechanism

The mechanism name associated with anonymous access is "ANONYMOUS".

The mechanism consists of a single message from the client to the

server. The client sends optional trace information in the form of a

human readable string. The trace information should take one of

three forms: an Internet email address, an opaque string which does

not contain the '@' character and can be interpreted by the system

administrator of the client's domain, or nothing. For privacy

reasons, an Internet email address should only be used with

permission from the user.

A server which permits anonymous access will announce support for the

ANONYMOUS mechanism, and allow anyone to log in using that mechanism,

usually with restricted access.

The formal grammar for the client message using Augmented BNF [ABNF]

follows.

message = [email / token]

TCHAR = %x20-3F / %x41-7E

;; any printable US-ASCII character except '@'

email = addr-spec

;; as defined in [IMAIL], except with no free

;; insertion of linear-white-space, and the

;; local-part MUST either be entirely enclosed in

;; quotes or entirely unquoted

token = 1*255TCHAR

3. Example

Here is a sample anonymous login between an IMAP client and server.

In this example, "C:" and "S:" indicate lines sent by the client and

server respectively. If such lines are wrapped without a new "C:" or

"S:" label, then the wrapping is for editorial clarity and is not

part of the command.

Note that this example uses the IMAP profile [IMAP4] of SASL. The

base64 encoding of challenges and responses, as well as the "+ "

preceding the responses are part of the IMAP4 profile, not part of

SASL itself. Newer profiles of SASL will include the client message

with the AUTHENTICATE command itself so the extra round trip below

(the server response with an empty "+ ") can be eliminated.

In this example, the user's opaque identification token is "sirhc".

S: * OK IMAP4 server ready

C: A001 CAPABILITY

S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=ANONYMOUS

S: A001 OK done

C: A002 AUTHENTICATE ANONYMOUS

S: +

C: c2lyaGM=

S: A003 OK Welcome, trace information has been logged.

4. Security Considerations

The anonymous mechanism grants access to information by anyone. For

this reason it should be disabled by default so the administrator can

make an eXPlicit decision to enable it.

If the anonymous user has any write privileges, a denial of service

attack is possible by filling up all available space. This can be

prevented by disabling all write access by anonymous users.

If anonymous users have read and write access to the same area, the

server can be used as a communication mechanism to anonymously

exchange information. Servers which accept anonymous submissions

should implement the common "drop box" model which forbids anonymous

read access to the area where anonymous submissions are accepted.

If the anonymous user can run many expensive operations (e.g., an

IMAP SEARCH BODY command), this could enable a denial of service

attack. Servers are encouraged to limit the number of anonymous

users and reduce their priority or limit their resource usage.

If there is no idle timeout for the anonymous user and there is a

limit on the number of anonymous users, a denial of service attack is

enabled. Servers should implement an idle timeout for anonymous

users.

The trace information is not authenticated so it can be falsified.

This can be used as an attempt to get someone else in trouble for

access to questionable information. Administrators trying to trace

abuse need to realize this information may be falsified.

A client which uses the user's correct email address as trace

information without explicit permission may violate that user's

privacy. Information about who accesses an anonymous archive on a

sensitive subject (e.g., sexual abuse) has strong privacy needs.

Clients should not send the email address without explicit permission

of the user and should offer the option of supplying no trace token

-- thus only exposing the source IP address and time. Anonymous

proxy servers could enhance this privacy, but would have to consider

the resulting potential denial of service attacks.

Anonymous connections are susceptible to man in the middle attacks

which view or alter the data transferred. Clients and servers are

encouraged to support external integrity and encryption mechanisms.

Protocols which fail to require an explicit anonymous login are more

susceptible to break-ins given certain common implementation

techniques. Specifically, Unix servers which offer user login may

initially start up as root and switch to the appropriate user id

after an explicit login command. Normally such servers refuse all

data access commands prior to explicit login and may enter a

restricted security environment (e.g., the Unix chroot function) for

anonymous users. If anonymous access is not explicitly requested,

the entire data access machinery is exposed to external security

attacks without the chance for explicit protective measures.

Protocols which offer restricted data access should not allow

anonymous data access without an explicit login step.

5. References

[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax

Specifications: ABNF", RFC2234, November 1997.

[IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text

Messages", STD 11, RFC822, August 1982.

[IMAP4] Crispin, M., "Internet Message Access Protocol - Version

4rev1", RFC2060, December 1996.

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", RFC2119, March 1997.

[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",

RFC2222, October 1997.

6. Author's Address

Chris Newman

Innosoft International, Inc.

1050 Lakes Drive

West Covina, CA 91790 USA

Email: chris.newman@innosoft.com

7. Full Copyright Statement

Copyright (C) The Internet Society (1997). All Rights Reserved.

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有