idnits 2.17.1 draft-lakhiani-adminprohib-authreqd-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 66: '...se ICMP messages SHOULD only be sent b...' RFC 2119 keyword, line 105: '...he ICMP datagram SHOULD contain as muc...' RFC 2119 keyword, line 107: '...r (and user data) MUST be identical to...' RFC 2119 keyword, line 118: '...er. This message MUST only be sent by ...' RFC 2119 keyword, line 129: '...tection against such attacks SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2002) is 7893 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 793' is mentioned on line 49, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Unused Reference: 'RFC792' is defined on line 134, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 137, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Lakhiani 3 INTERNET DRAFT S. Ostermann 4 Ohio University 6 Expiration Date: March 2003 September 2002 8 A Proposal for ICMP "Authentication Required" Messages 10 draft-lakhiani-adminprohib-authreqd-02.txt 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 2. Abstract 35 The current ICMP "Destination Unreachable - Communication 36 Administratively Prohibited" message conveys one bit of information: 37 the gateway is administratively filtering your packets. This memo 38 proposes the addition of an ICMP "Authentication Required" response 39 to provide the more specific message that packets are being 40 administratively prohibited until successful authentication. 42 3. Introduction 44 There are situations where the ICMP Administratively Denied message 45 may not provide sufficient information to an end host. Specifically, 46 access may be denied only until the successful completion of 47 authentication. Currently there is no standard mechanism for 48 conveying this message back to the host. All the firewall can do is 49 silently drop the packet, send a TCP Reset packet [RFC 793], or send 50 an ICMP "Administratively Prohibited" message. We suggest that a new 51 ICMP code "Authentication Required" be made available. This would be 52 useful to inform the host of lack of authentication. How this 53 information gets back to the user on that host is beyond the scope of 54 this document. 56 4. Suggested Use 58 Let us consider an example to better understand the use of this ICMP 59 message. Suppose a host attempts to communicate over a wireless 60 network that requires the user to authenticate himself to a Kerberos 61 [RFC1510] server. While the gateway drops packets coming from this 62 host, it would be useful to send "Authentication Required" ICMP 63 messages back to the host. The user on that host could then contact 64 the Kerberos server to authenticate himself. 66 In general, these ICMP messages SHOULD only be sent by a gateway that 67 is willing to allow communications through it upon successful 68 completion of authentication. Determining the appropriate 69 authentication mechanism is beyond the scope of this document. 71 5. Message Format 73 0 1 2 3 74 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 75 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 76 | Type = 3 | Code = 16 | Checksum | 77 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 | Unused | 79 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 | Original Message Header | 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 Type 85 3 87 Code 89 16 = Authentication Required 91 Checksum 93 The checksum is the 16-bit one's complement of the one's 94 complement sum of the ICMP message starting with the ICMP Type. 96 For computing the checksum, the checksum field should be zero. 97 This checksum may be replaced in the future. 99 Original Message Header 101 Historically, every ICMP error message has included the Internet 102 header and at least the first 8 data bytes of the datagram that 103 triggered the error. This is no longer adequate, due to the use 104 of IP-in-IP tunneling and other technologies [RFC1812]. Therefore, 105 the ICMP datagram SHOULD contain as much of the original datagram 106 as possible without the length of the ICMP datagram exceeding 576 107 bytes. The returned IP header (and user data) MUST be identical to 108 that which was received, except that the router is not required to 109 undo any modifications to the IP header that are normally 110 performed in forwarding that were performed before the error was 111 detected (e.g., decrementing the TTL, or updating options). 113 Description 115 The gateway sends a "Destination Unreachable - Authentication 116 Required" message to a host in the situation where it receives 117 datagrams from that host before the host has authenticated itself 118 to the authentication server. This message MUST only be sent by a 119 gateway willing to allow communications from that host through it 120 upon successful authentication. 122 6. Security Considerations 124 A malicious user could use this mechanism to trick a user or host 125 into revealing authentication information to unknown servers. On 126 the other hand a client system that does not know anything about 127 the appropriate authentication mechanism to be used may not use 128 the network at all. This could be exploited to launch a denial of 129 service attack. Protection against such attacks SHOULD be 130 employed, but is out of the scope of this document. 132 7. References 134 [RFC792] "Internet Control Message Protocol". J. Postel. 135 September 1981. 137 [RFC793] "Transmission Control Protocol". J. Postel. September 138 1981. 140 [RFC1812] "Requirements for IP Version 4 Routers". F. Baker. June 141 1995. 143 [RFC1510] "The Kerberos Network Authentication Service (V5)". J. 145 Kohl, C. Neuman. September 1993. 147 8. Author Information 149 Avinash Lakhiani 150 Ohio University 151 301, Stocker Center 152 Athens, OH 45701 154 EMail: avinash.lakhiani@ohiou.edu 156 Shawn Ostermann 157 School of Electrical Engineering and Computer Science 158 Ohio University 159 322B, Stocker Center 160 Athens, OH 45701 162 EMail: ostermann@cs.ohiou.edu