Network Working Group R. Hedberg
Internet-Draft Stockholm university
Expires: July 1, 2004 January 2004
Simple Policy Control Protocol
draft-hedberg-spocp-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 1, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Hedberg Expires July 1, 2004 [Page 1]
Internet-Draft SPOCP January 2004
Table of Contents
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The SPOCP model . . . . . . . . . . . . . . . . . . . . . . 5
4. SPOCP functions . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Input grammar . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Output grammar . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 QUERY . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4 STARTTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5 ADD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6 DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7 LIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.8 LOGOUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.9 BEGIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.10 COMMIT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.11 ROLLBACK . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.12 SUBJECT . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.13 AUTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.14 CAPABILITY . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.15 BCOND . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. The theory behind return-info . . . . . . . . . . . . . . . 14
6. Security considerations . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . 16
A. SPOCP Reply Codes . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . 19
Hedberg Expires July 1, 2004 [Page 2]
Internet-Draft SPOCP January 2004
1. Abstract
Hedberg Expires July 1, 2004 [Page 3]
Internet-Draft SPOCP January 2004
2. Introduction
The objective of SPOCP is to support the use of a generalized access
control service (as defined in [RFC2828]) by a multitude of
applications. The protocol not only supports querying for access
control decisions but also for administration of security policies.
The significance of the term generalized is that SPOCP is not written
to support a specific set of applications but should be possible to
use by almost any application. And one SPOCP server should be able to
service a set of applications simultaneously.
SPOCP is independent of the particular transmission subsystem and
requires only a reliable ordered data stream channel. A companion
document [SPOCP/TCP] describes one implementation of SPOCP over TCP.
Hedberg Expires July 1, 2004 [Page 4]
Internet-Draft SPOCP January 2004
3. The SPOCP model
The SPOCP design is based on the 'PULL sequence' as described in RFC
2904 [RFC2904]. That is, a application/some service equipment queries
the access control service as to the permission for a specific user
to access/use a specific resource.
This has some consequences; one of them being that it is in fact the
service equipment that makes the decision whether a specific user
shall be allowed to perform a specific operation or not. The access
control service can only return a recommendation, it can not enforce
anything.
One of the design criteria behind Spocp is that it is not uncommon
that a simple yes/no answer is sufficient. There are lots of cases
where a yes, but.. answer is more appropriate. Hence we have added
the concept of return-info, some information that can be returned
together with a positive reply. A negative reply is never ackompanied
by any return information.
Another design criteria was that we did not want to copy lots of
information that are already present in different information
resources (like a enterprise directory, a whois server, DNS or what
have you). This service should be able to use the information where
it is and not demand a local copy. Now, we do acknowledge that there
are cases where due to security of performance concerns you might
have to keep local copies but our aim was to make this a optimization
and not the standard. To solve this equation we have added boundary
conditions. Boundary conditions, which might be things like; the time
has to be between 0800 and 1700 on a working day or the entity that
wants to do this has to belong to the group 'admin' as defined in the
enterprise directory, are evaluated after a request for a permission
has match a policy stored in the authorization server.
And finally, any rule placed in the server represents a permission
for someone to use some resource. There are no negative rules, that
is rules that says that someone are not allowed to access a resource.
The reason for this was that the system compexity increases
substantially if negative rules are allowed.
How the service equipment finds the right access control service to
ask is outside the scope of this document but will be specified in a
separate draft where a access control service location mechanism
based on DNS is described.
Hedberg Expires July 1, 2004 [Page 5]
Internet-Draft SPOCP January 2004
4. SPOCP functions
A SPOCP connection consists of the establishment of a client/server
network connection, and subsequent client/server interactions. These
client/server interactions consist of a client command and a server
response
Commands in SPOCP consists of a keyword possibly followed by one or
more arguments. Keywords consists of printable ASCII characters.
Server data are only sent as a result of a client command
If the traffic between a client and a server, happens over TCP/IP,
then it can be protected by the use of TLS/SSL [RFC2246] and/or SASL
[RFC2222] The STARTTLS and AUTH commands are used to initialize the
TLS and SASL handshakes.
4.1 Input grammar
command = starttls / query / add / delete / list / bcondcom
logout / begin / commit / rollback / subjectcom / capability /
saslauth
starttls = "STARTTLS"
query = "QUERY" [path] s-expr
add = "ADD" [path] s-expr [ bcond [ return-info ]]
delete = "DELETE" [path] ruleid
list = "LIST" [path] *( "+"/"-" s-expr )
logout = "LOGOUT"
begin = "BEGIN"
commit = "COMMIT"
rollback = "ROLLBACK"
subjectcom = "SUBJECT" [ s-exp [ token ]]
capability = "CAPABILITY"
saslauth = "AUTH" mech token
bcondcom = "BCOND" ( "ADD" / "DELETE" / "REPLACE" ) bcondname
Hedberg Expires July 1, 2004 [Page 6]
Internet-Draft SPOCP January 2004
[ bcond ]
bcond = bcondexpr / bcondspec
bcondexpr = bcondor / bcondand / bcondnot / bcondref
bcondspec = bcondname ":" typespecific
bcondname = 1*dirchar
typespecific = octetstring
bcondref = "(" "ref" 1*dirchar ")"
bcondand = "(" "and" 1*bcondexpr ")"
bcondor = "(" "or" 1*bcondexpr ")"
bcondnot = "(" "not" bcondexpr ")"
mech = 1*pchar
ruleid = 1*pchar
path = "/" / 1*( "/" pathpart )
pathpart = 1*dirchar
dirchar = pchar / '-' / '_' / '.'
pchar = %x30-39 / %x41-5A / %x61-7A
token = octet-string
s-expr = ; defined in [SPOCP Sexp] with one restriction
that the tag of a list consists solely of dirchar's
4.2 Output grammar
spocp-response = *(multiline) singleline
multiline = multi-response
multi-response = "201" m-info
singleline = response
Hedberg Expires July 1, 2004 [Page 7]
Internet-Draft SPOCP January 2004
response = replycode [ octetstring ]
; replycode 201 can not appear in singleline responses
replycode = ( "2" / "3" / "4" / "5" ) digit digit [
octetstring ]
m-info = return-info / list-info
list-info = path ruleid s-expr [ return-info ]
return-info = [ mimecontenttype ] octetstring
mimecontenttype = ; as defined in [RFC2045]
octet-string = 1*byte
byte = %x00-FF
The MIME content-type attribute is an optional attribute which
describes the return-info data. This is a string with values defined
by [RFC2045]. This attribute is purely advisory; no validation of the
mime type information is required by this specification.
The format of the reply codes follows the common IETF principal as
used in SMTP [RFC0821] and HTTP [RFC1945] to mention a few.
The first digit of the Status-Code defines the class of response. The
last two digits do not have any categorization role. There are 5
values for the first digit:
1xx: Informational - Not used, but reserved for future use
2xx: Success - The action was successfully received, understood,
and accepted.
3xx: Redirection - Further action must be taken in order to
complete the request or an authentication handshake are in
progress
4xx: Client Error - The request contains bad syntax or cannot be
fulfilled
5xx: Server Error - The server failed to fulfill an apparently
valid request
A complete list of reply codes are given in Appendix A
Hedberg Expires July 1, 2004 [Page 8]
Internet-Draft SPOCP January 2004
4.3 QUERY
This command takes one argument, a S-expression representing the
access permission that is in question.
If a rule in the server matched the given S-expression and there is
return information coupled to that rule, the return information will
be returned together with the positive response, in the multipart. If
there are more than one rule that matches, only one of them will be
used to construct the response.
The upshot of this is that if there are more than one rule giving a
certain permission and all of these return different return-info then
a sequence of consecutive queries for this permission, might not
necessarily result in the return-info being the same in each reply.
That is, you can not assume that there exists any well defined and
consistent order between the rules.
Overlapping rules should therefore if possible be avoided, especially
if there are return information coupled to them.
*Note:* When a permission is checked, it is not checked against the
union of all the rules but against each rule separately.
4.4 STARTTLS
This command takes as of now, no arguments
If SSL/TLS is used the client is also expected to authenticate. If
the authentication fails the connection is immediately closed.
Downgrading to not use TLS/SSL is not possible,
Any commands sent by the client after the server has received this
command and before the TLS/SSL negotiation is completed will be
silently ignored.
The client as well as the server MUST check its understanding of the
opponent's host name against its identity as presented in the
opponent's Certificate message, in order to prevent man-in-the-middle
attacks.
Matching from the clients point of view is performed according to
these rules:
The client MUST use the server host name it used to open the SPOCP
connection as the value to compare against the server name as
expressed in the server's certificate. The client MUST NOT use the
server's canonical DNS name or any other derived form of name.
Hedberg Expires July 1, 2004 [Page 9]
Internet-Draft SPOCP January 2004
If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's
identity.
If more than one identity of a given type is present in the
certificate (e.g. more than one dNSName name), a match in any one
of the set is considered acceptable.
Matching is case-insensitive. If the host name does not match the
dNSName-based identity in the certificate per the above check,
user-oriented clients SHOULD either notify the user (clients MAY give
the user the opportunity to continue with the connection in any case)
or terminate the connection and indicate that the server's identity
is suspect. Automated clients SHOULD close the connection, returning
and/or logging an error indicating that the server's identity is
suspect.
Beyond the server identity checks described in this section, clients
SHOULD be prepared to do further checking to ensure that the server
is authorized to provide the service it is observed to provide. The
client MAY need to make use of local policy information.
4.5 ADD
The command has at least one argument and at the most three. The
first argument is the S-expression that the administrator wants to
store in the rule database. The other arguments, if present, is the
boundary condition connected to this rules and possible also static
return information.
The second argument, if present, can either be a name, which then
refers to a boundary condition stored somewhere on the server, or it
can be a direct specification of a boundary condition. If there is
the need to define some return info but no boundary condition the
second argument should be the string "NULL" which then signifies the
null boundary condition.
The third argument, if present, really consists of two parts; a
optional mime content-type specification and then the information
which is treated by the server as a number of bytes and never
interpreted in any way. It will be returned to the client exactly as
given.
4.6 DELETE
Only one argument and that is the ruleID of the rule to be deleted.
Every rule in the server MUST have a ruleID and if exactly the same
Hedberg Expires July 1, 2004 [Page 10]
Internet-Draft SPOCP January 2004
rule appears in several servers the ruleID should be the same. To
accomplish this the MD5 [RFC1321] message-digest of the S-expression
is used as the ruleID.
4.7 LIST
The arguments are a list of sub elements.
The less permissive comparison, as specified in [SPOCP Sexp], is used
here. The difference, compared to usage in connection with other
commands, is that you are able to define different directions for the
comparison with this command. If you use '+' as order specifier the
order is the same as used in the query command, that is you search
for a rule that is more permissive than the S-expression specified in
the query. If on the other hand you specify the '-' as order
specifier, you will look for rules that are less permissive than the
specification. The syntax for this command allows you to specify
different directions for each sub element, hence you can specify:
LIST +spocp -(8:resource) +(6:action4:read) -(7:subject(3:uid))
Which then will match rules like:
(5:spocp(8:resource(4:file3:etc6:groups))(6:action4:read)(7:subject(3:uid3:100)))
(5:spocp(8:resource(4:file3:etc6:passwd))(6:action4:read)(7:subject(3:uid3:50)))
Since every rule in the SPOCP server MUST be a list S-expression, the
sub elements that we are talking about here are the first level
elements of that list.
*Note:* that since the less permissive comparison is used, you can
not easily list all rules that are valid for ranges of values. If you
for instance have sub elements in rules that look like this:
(age (* range numeric le 6))
(age (* range numeric ge 7 le 18))
(age (* range numeric gt 18 le 40))
(age (* range numeric ge 41 lt 65))
(age (* range numeric ge 65))
Then "LIST +3:age -(1:*5:range2:le2:10)" will match rule 1 but not
rule 2. One of two partly overlapping ranges can never be regarded as
less permissive than the other. If you really want to know every rule
Hedberg Expires July 1, 2004 [Page 11]
Internet-Draft SPOCP January 2004
that concerns entities who's age are less than or equal to 10, then
you have to combine the result of several queries: for instance the
one specified above and "LIST +3:age +2:10".
4.8 LOGOUT
No argument. When the server receives this command it will
immediately close down the connection.
4.9 BEGIN
No argument.
Marks the start of a transaction, that is a number of commands that
should be applied as 'one'
4.10 COMMIT
No argument.
Applies all the commands that has been specified within a
transaction.
4.11 ROLLBACK
No argument.
Clears the list of commands that has been added since the 'begin'
commands was issued
4.12 SUBJECT
One or two arguments, the first being the 'user' name, the other a
token that proves to the server that the user really is who she says
she is.
4.13 AUTH
This command takes two arguments: an authentication mechanism and an
initial authentication handshake token. This document only specified
SASL handshakes but other may be defined in the future.
SASL-mechanisms are named using the "SASL:"-prefix; eg SASL:GSSAPI or
SASL:SCRAM-MD5. A list of supported authentication mechanisms are
listed (among other things) in the output of the CAPABILITY command.
If the server supports and is willing to use the requested mechanism
the server sends the token to the underlying mechanism and returns a
301 (Authentication in progress) with a return token for the client
Hedberg Expires July 1, 2004 [Page 12]
Internet-Draft SPOCP January 2004
mechanism. The client must either continue the handshake with a new
AUTH command using the same mechanism or a LOGOUT command. If the
handshake fails the server must issue a 508 (Authentication error)
and close the connection. If the server does not support the
requested mechanism a 405 (Argument error) is returned and the
connection is closed.
After a success full handshake the client and server uses whatever
protection layer has been negotiated (integrity and/or
confidentiality) and sends SASL-wrapped tokens instead of the raw
bytes.
4.14 CAPABILITY
This command takes no arguments. The return is a 200 with an token
containing a space (ascii 32)-separated list of capitalized ascii
strings signifying server capabilities. Currently the only
capabilities supported are "SASL:"-prefixed SASL [RFC2222]
authentication mechanism eg "SASL:GSSAPI".
4.15 BCOND
This command takes two or three arguments: and action to perform a
name of a boundary condition and depending on the action a third
which would be a specification of a boundary condition.
Boundary conditions are tests that are run when the rule they are
connected to is more permissive than the query. Boundary conditions
can return TRUE or FALSE, which means that even though the rule
matches the final decision is based on the result of the boundary
condition evaluation.
Hedberg Expires July 1, 2004 [Page 13]
Internet-Draft SPOCP January 2004
5. The theory behind return-info
The user is permitted to access the resource, but if she does so
special care should be taken as to logging
The user is permitted to access the resource, but belongs to a set
of users that should use a special instance of the resource.
The user is permitted to access the resource, and the application
can cache this information for a specified amount of time
If the application is a proxy, and the user has the permission to
use the end resource the proxy should use the one-time-password
returned in the return-info when accessing the resource
As has been described earlier, an administrator can set the
return-info when a access rule is added to the access control
service. This kind of return-info is static and will not be changed
before it is returned to a application.
To support dynamic construction of return-info in our implementation
of a SPOCP server we are allowing back ends that handle boundary
conditions to construct and return return-info when condition is
evaluated to TRUE. This has meant that we have a couple of back ends
connected with boundary conditions that are there more for the side
effect that they produce dynamic return-info then for really checking
a necessary boundary condition.
Hedberg Expires July 1, 2004 [Page 14]
Internet-Draft SPOCP January 2004
6. Security considerations
Introducing middleware components have a lot of benefits but also
opens new ways of attacking applications. Making a application
dependent on a middleware component disregarding which service it
provides means that the application is not more secure than the least
secure of the services it is using. There for the aim of any
implementer of or user of a middleware service must be to make it
safer than any of the applications it is serving.
If boundary conditions are used the information that they use for
their evaluation is as important to protect and verify as the rules
that the server is using.
Hedberg Expires July 1, 2004 [Page 15]
Internet-Draft SPOCP January 2004
References
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1945] Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
2000.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M. and D.
Spence, "AAA Authorization Framework", RFC 2904, August
2000.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[SPOCP/TCP]
Hedberg, R., "The Simple Policy Control Protocol over TCP/
IP".
[SPOCP Sexp]
Hedberg, R. and O. Bandmann, "Restricted S-expressions for
usage in a generalized access control service".
Author's Address
Roland Hedberg
Stockholm university
Kasamark 114
Umea 90586
Sweden
Phone: +46 90 147275
EMail: roland@it.su.se
Hedberg Expires July 1, 2004 [Page 16]
Internet-Draft SPOCP January 2004
Appendix A. SPOCP Reply Codes
+--------+-----------------+----------------------------------------+
| Respon | Response text | Description |
| se | (might be | |
| code | present) | |
+--------+-----------------+----------------------------------------+
| 200 | Ok | Command accepted and executed |
| | | |
| 201 | | Multi line response |
| | | |
| 202 | Denied | Query did not match any stored policy |
| | | |
| 203 | Bye | Server is closing connection |
| | | |
| 204 | Transaction | |
| | complete | |
| | | |
| 301 | Authentication | |
| | in progress | |
| | | |
| 400 | Syntax error | |
| | | |
| 401 | Already in | |
| | operation | |
| | | |
| 402 | Too many | |
| | arguments | |
| | | |
| 403 | Line too long | |
| | | |
| 404 | Access denied | |
| | | |
| 405 | Argument error | |
| | | |
| 406 | Not supported | |
| | | |
| 407 | Already exits | Rules or client specifications can not |
| | | be overwritten |
| | | |
| 408 | Input error | |
| | | |
| 409 | Protocol error | |
| | | |
| 410 | Unknown command | |
| | | |
| 411 | Size limit | The total number of bytes in the |
| | exceeded | command exceeded the limit set by the |
Hedberg Expires July 1, 2004 [Page 17]
Internet-Draft SPOCP January 2004
| | | server |
| | | |
| 500 | Operations | Permanent operations error |
| | error | |
| | | |
| 501 | Service not | |
| | available | |
| | | |
| 502 | Information | When a remote service is not |
| | unavailable | available, this is when a boundary |
| | | condition can not be checked. |
| | | |
| 503 | Unknown ID | |
| | | |
| 504 | Already active | |
| | | |
| 505 | Internal error | |
| | | |
| 506 | Time limit | |
| | exceeded | |
| | | |
| 507 | Other error | For example error encountered while |
| | | using back ends |
| | | |
| 509 | Authentication | |
| | error | |
| | | |
| 510 | Not implemented | |
+--------+-----------------+----------------------------------------+
Hedberg Expires July 1, 2004 [Page 18]
Internet-Draft SPOCP January 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 assignees.
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
Hedberg Expires July 1, 2004 [Page 19]
Internet-Draft SPOCP January 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hedberg Expires July 1, 2004 [Page 20]