idnits 2.17.1 draft-mariblanca-aaa-eap-lla-01.txt: -(161): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 5) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 2434' is mentioned on line 119, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'RFC 3575' is mentioned on line 120, but not defined == Missing Reference: 'RFC 3588' is mentioned on line 120, but not defined ** Obsolete undefined reference: RFC 3588 (Obsoleted by RFC 6733) == Unused Reference: 'RFC3575' is defined on line 149, but no explicit reference was found in the text == Unused Reference: 'RFC3588' is defined on line 152, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 157, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-07 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group David Mariblanca 3 INTERNET-DRAFT Ericsson 4 Expires: December 2004 6 June, 2004 8 EAP lower layer attributes for AAA protocols 9 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This document is an individual submission to the IETF. Comments 32 should be directed to the author. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document defines a new AVP to be transported in RADIUS or 41 Diameter when EAP is carried over these protocols. The purpose of 42 this AVP is to determine which layer 2 protocol was used to 43 encapsulate the EAP messages at the point they were initiated. 45 TABLE OF CONTENTS 47 1. Introduction.......................................................3 48 1.1 Abbreviations....................................................3 49 2. Conventions........................................................3 50 3. Attributes.........................................................3 51 3.1 EAP-Lower-Layer AVP................................................3 52 4. Acknowledgements...................................................5 53 5. Authors' Addresses.................................................5 54 6. References.........................................................5 55 1. Introduction 57 This document defines a new AVP to be transported in RADIUS or 58 Diameter when EAP [EAP] is carried over these protocols. This 59 information will be useful for the EAP server to determine which 60 service initiated the EAP procedure. This situation will be common 61 when EAP is used over a layer 2 protocol for which the EAP server is 62 not one of the termination points. The access node where EAP is 63 decapsulated from such layer 2 protocol will package the EAP messages 64 over RADIUS [RFC3579] or Diameter [DEAPapp] and send them to the EAP 65 server, which in some situations will need to have some information 66 about the origin of the EAP messages. For example, the EAP server may 67 wish to allow/deny access from a given lower layer for every 68 subscriber. The AVP defined in this document will provide this 69 information to the EAP server. The EAP server MAY use this AVP at the 70 moment of the authorization decision, and once this decision is 71 taken, the rest of the exchange SHOULD NOT be affected. 73 1.1 Abbreviations 75 EAP Extensible Authentication Protocol 77 2. Conventions 79 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 80 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 81 they appear in this document, are to be interpreted as described in 82 [RFC2119]. 84 3. Attributes 86 3.1 EAP-Lower-Layer AVP 88 The EAP-Lower-Layer AVP indicates the layer 2 protocol which has been 89 used to carry EAP messages. This attribute MAY be used by access 90 devices acting as EAP pass-through authenticators, such as network 91 access servers passing EAP from a PPP interface to a RADIUS or 92 DIAMETER interface. 94 This AVP MAY be included in the Diameter-EAP-Request (DER) Command. 95 It MUST NOT be present in the Diameter-EAP-Answer (DEA) Command. 96 In case of RADIUS, the EAP-Lower-Layer AVP MAY be included in the 97 Access-Request message, and MUST NOT be included in any other RADIUS 98 message. 100 The format of the EAP-Lower-Layer AVP is shown below. 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 |EAP-Lower-Layer| Length = 1 | Underlying Protocol | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 The values for this attribute are: 110 Protocol Value 111 PPP 1 112 802.1X 2 113 IKEv2 3 114 PANA 4 116 4. IANA considerations 118 New values for the EAP-Lower-Layer AVP are to be allocated by First 119 Come First Served [RFC 2434], in accordance with RADIUS and Diameter 120 IANA guidelines [RFC 3575] [RFC 3588]. 122 4. Acknowledgements 124 The author would like to thank Hannes Tschofenig, Bernard Aboba and 125 Jari Arkko for their help in the creation and edition of this 126 document. 128 5. Authors' Addresses 130 David Mariblanca 131 Ericsson Espana S.A. 132 28033 Madrid 133 Spain 135 Phone: +34-91-339-3422 136 Email: david.mariblanca@ericsson.com 138 6. Normative References 140 [EAP] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H. 141 Levkowetz, "Extensible Authentication Protocol (EAP)", 142 draft-ietf-eap-rfc2284bis-09 (work in progress), February 143 2004. 145 [DEAPapp] P. Eronen, T. Hiller, G. Zorn, �Diameter Extensible 146 Authentication Protocol (EAP) Application�, draft-ietf- 147 aaa-eap-07.txt (work in progress), June 2004. 149 [RFC3575] B. Aboba, �IANA considerations for RADIUS�, RFC 3575, 150 July 2003. 152 [RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko, 153 �Diameter Base Protocol�, RFC 3588, September 2003 155 7. Informative References 157 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 158 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 159 October 1998. 161 [RFC3579] B. Aboba, P. Calhoun, �RADIUS (Remote Authentication Dial 162 In User Service) Support For Extensible Authentication 163 Protocol (EAP)�, RFC 3579, September 2003. 165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 166 Requirement Levels", BCP 14, RFC 2119, March 1997. 168 Full Copyright Statement 170 Copyright (C) The Internet Society (2004). All Rights Reserved. 172 This document and translations of it may be copied and furnished to 173 others, and derivative works that comment on or otherwise explain it 174 or assist in its implementation may be prepared, copied, published 175 and distributed, in whole or in part, without restriction of any 176 kind, provided that the above copyright notice and this paragraph are 177 included on all such copies and derivative works. However, this 178 document itself may not be modified in any way, such as by removing 179 the copyright notice or references to the Internet Society or other 180 Internet organizations, except as needed for the purpose of 181 developing Internet standards in which case the procedures for 182 copyrights defined in the Internet Standards process must be 183 followed, or as required to translate it into languages other than 184 English. 186 The limited permissions granted above are perpetual and will not be 187 revoked by the Internet Society or its successors or assigns. 189 This document and the information contained herein is provided on an 190 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 191 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 192 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 193 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 194 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 196 Acknowledgment 198 Funding for the RFC Editor function is currently provided by the 199 Internet Society.