idnits 2.17.1 draft-wilkinson-afs3-bos-identities-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 102: '...our of this function MUST be identical...' RFC 2119 keyword, line 117: '...of this function MUST be identical to ...' RFC 2119 keyword, line 129: '...s called, cookie MUST be set to 0. Th...' RFC 2119 keyword, line 138: '... This call MUST return all super use...' RFC 2119 keyword, line 152: '...s described within this document, MUST...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 7, 2010) is 4890 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-brashear-afs3-pts-extended-names-07 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Wilkinson 3 Internet-Draft YFS 4 Intended status: Informational December 7, 2010 5 Expires: June 10, 2011 7 Adding Extended Authentication Names to the Bos Super User list 8 draft-wilkinson-afs3-bos-identities-00 10 Abstract 12 This document describes an additional set of RX remote procedure 13 calls which may be used to managed extended authenticated names 14 within the AFS-3 basic overseer service's SuperUser list 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on June 10, 2011. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Error codes . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. RPC Interface . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3.1. AddSuperIdentity . . . . . . . . . . . . . . . . . . . . . 3 51 3.2. DeleteSuperIdentity . . . . . . . . . . . . . . . . . . . . 4 52 3.3. ListSuperIdentities . . . . . . . . . . . . . . . . . . . . 4 53 4. Behaviour of existing RPCs . . . . . . . . . . . . . . . . . . 5 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 56 7. AFS-3 Registry Considerations . . . . . . . . . . . . . . . . . 5 57 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 1. Introduction 62 AFS-3 provides a management service (the "basic overseer service", or 63 "bos" for short) which manages service wide configuration 64 information, and launches the daemons which provide each of the 65 individual AFS services. This management service also maintains a 66 list of identities which are granted super user privileges to bos 67 itself, and to the services it manages. This list is maintained via 68 a number of RX remote procedure calls which can be used to list, add, 69 and remove identities. Traditionally, AFS-3's security model was 70 Kerberos v4 based, and the existing RPCs for managing the super user 71 list are based around Kerberos v4 names. 73 Extended authentication names [I-D.brashear-afs3-pts-extended-names] 74 provide a mechanism for encapsulating a wider variety of name types 75 within the AFS-3 system. These new identity types bring with them a 76 requirement to be able to manipulate bos super user lists containing 77 extended identities. 79 2. Error codes 81 The existing BZNOENT, BZEXISTS and BZPERM error codes are used by the 82 RPCs defined within this document. 84 3. RPC Interface 86 Three new RPCs are defined for the bos service. These are direct 87 equivalents of existing RPCs, with the exception that they add 88 support for extended authentication names. 90 3.1. AddSuperIdentity 92 This is a direct equivalent of the existing AddSUser call. It adds 93 an identity to the service's super user list. 95 AddSuperIdentity(IN struct PrAuthName *name) = XXX; 97 On success, the call returns 0. If the user doesn't have sufficient 98 permission, then BZACCESS is returned. If the given identity already 99 exists within the super user list BZEXISTS is returned. 101 When called with a name with the PRAUTHTYPE_KRB4 data type (a 102 Kerberos v4 name), the behaviour of this function MUST be identical 103 to that of the existing AddSUser function. 105 3.2. DeleteSuperIdentity 107 This is a direct equivalent of the existing DeleteSUser call. It 108 deletes an identity from the service's super user list. 110 DeleteSuperIdentity(IN struct PRAuthName *name) = XXX; 112 On success, the call returns 0. If the user doesn't have sufficient 113 permission, then BZACCESS is returned. If the identity doesn't exist 114 within the super user list, then BZNOENT is returned. 116 When called with a name with the PRAUTHTYPE_KRB4 data type the 117 behaviour of this function MUST be identical to that of the existing 118 DeleteSUser function 120 3.3. ListSuperIdentities 122 This is an equivalent to the existing ListSUsers call. It provides a 123 mechanism for building an iterator over the server's super user list. 125 ListSuperIdentities(IN afs_int32 cookie, 126 OUT struct PRAuthName *name, 127 OUT afs_int32 *newcookie) = XXX; 129 The first time this function is called, cookie MUST be set to 0. The 130 server will then return the first entry in the super user list (or 131 BZNOENT, if the super user list is empty). In newcookie, it will 132 return a value that can be used to obtain the next entry from the 133 server, or 0 if the current entry is the last one. The client may 134 then repeat its call using newcookie as the cookie value, until it 135 has obtained the desired number of entries, or until newcookie is 0, 136 and the iteration is complete. 138 This call MUST return all super users registered with the bos server, 139 regardless of whether they were created using the RPCs defined in 140 this document, or by the existing AFS-3 bos RPCs. Names created 141 through the AddSUser interface should be returned as PRAuthNames with 142 the PRAUTHTYPE_KRB4 type, as detailed in the extended authentication 143 name specification. 145 On success, the RPC will return 0. If the user doesn't have 146 sufficient permissions to read the super user list, then BZACCESS is 147 returned. If an entry pointed to by a specific cookie has ceased to 148 exist, or if the super user list is empty, then BZNOENT is returned. 150 4. Behaviour of existing RPCs 152 The existing RPCs, and the ones described within this document, MUST 153 both provide access to the same super user list. Where equivalent 154 functionality is available to both new, and old, RPCs, there should 155 be no observable difference between using the old or new forms. 157 Calling AddSUser must have an identical result to calling 158 AddSuperIdentity on the corresponding Kerberos v4 name 160 Calling DeleteSUser must have an identical result to calling 161 DeleteSuperIdentity on the corresponding Kerberos v4 name 163 The ListSUsers RPC only iterates over Kerberos v4 form names. Due to 164 the behaviour of existing clients spaces MUST NOT be left in the 165 iteration sequence for extended identities in the user list. This 166 means that ListSUsers will present an incomplete view of the super 167 identities present on a particular server. Consideration SHOULD, 168 therefore, be given to removing the ListSUsers call when support for 169 the RPCs listed in this document is added. 171 5. Security Considerations 173 Current AFS-3 implementations provide a high degree of access to 174 identities on the super user list. Whilst this document doesn't 175 proscribe particular levels of access control for the RPCs it 176 specifies, implementers should consider whether restricting these 177 RPCs to particular security classes, and protection levels, is 178 appropriate 180 PrAuthNames contain both display and exported name forms, with the 181 display name being provided purely for user interface purposes. When 182 returning names to the client, servers MUST regenerate the display 183 name from the given exported name. Where regeneration is impossible 184 (for instance, because the name's underlying mechanism is 185 unavailable), servers must indicate that the display name is 186 unverified. 188 6. IANA Considerations 190 This document doesn't require any IANA registrations. 192 7. AFS-3 Registry Considerations 194 This documentation requires the registration of code points for the 3 195 new RPCS detailed above. 197 8. Normative References 199 [I-D.brashear-afs3-pts-extended-names] 200 Brashear, D., "Authentication Name Mapping extension for 201 AFS-3 Protection Service", 202 draft-brashear-afs3-pts-extended-names-07 (work in 203 progress), November 2010. 205 Author's Address 207 Simon Wilkinson 208 Your File System Inc 210 Email: simon@sxw.org.uk