IPP> IPP Authorization Models - excerpt from RFC 2905 - pleas e review

IPP> IPP Authorization Models - excerpt from RFC 2905 - pleas e review

IPP> IPP Authorization Models - excerpt from RFC 2905 - pleas e review

McDonald, Ira imcdonald at sharplabs.com
Mon Oct 2 17:46:55 EDT 2000


Hi Carl-Uno,

History:

There was an IETF AAA (Authentication, Authorization,
and Accounting) WG - as the RFC 2903-2905 documents
state, the IETF AAA WG was refocused narrowly on
Mobile IP and a few other topics.

The Generic AAA models and scenarios work was moved
into an IRTF (Internet Research Task Force - longterm)
AAAarch WG - although published as RFCs they state that
they are still 'work-in-progress'.

I think they've chosen the most interesting scenario
for the future of IPP in wireless and other nextgen
environments - print-by-reference interactions between
the File Server holding the URL contents and the IPP
Printer.

Cheers,
- Ira McDonald

-----Original Message-----
From: Carl-Uno Manros [mailto:carl at manros.com]
Sent: Monday, October 02, 2000 12:49 PM
To: McDonald, Ira; ipp at pwg.org
Subject: RE: IPP> IPP Authorization Models - excerpt from RFC 2905 -
please review


Ira,

Thanks for pointing this out. Indeed I initiated a request to the AAA people
some two years ago that this was a problem we wanted solved for IPP. Earlier
this year I was told that the subject had been taken off the AAA agenda, but
I am happy to learn that somebody has done something after all..

Carl-Uno

> -----Original Message-----
> From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of McDonald,
> Ira
> Sent: Monday, October 02, 2000 11:52 AM
> To: 'ipp at pwg.org'
> Subject: IPP> IPP Authorization Models - excerpt from RFC 2905 - please
> review
>
>
> Copies: IETF IPP WG <ipp at pwg.org>
>
> Hi folks,                                        Monday (2 October 2000)
>
> I found this interesting section on possible IPP authorization models
> in 'AAA Authorization Application Examples', RFC 2905, August 2000.
> It addresses IPP print-by-reference (the Print-URI operation).
>
> Feedback to the IRTF (Internet Research Task Force) AAAarch RG (Research
> Group) from IPP designers and implementors would be timely.
>
> Cheers,
> - Ira McDonald, consulting architect at Xerox and Sharp
>   High North Inc
>
> ------------------------------------------------------------------------
>
> [from 'ftp://ftp.isi.edu/in-notes/rfc2905.txt', pages 25-28]
>
> 5.  Internet Printing
>
>    The Internet Printing Protocol, IPP [14], has some potentially
>    complex authorization requirements, in particular with the "print-
>    by-reference" model.  The following attempts to describe some
>    possible ways in which an authorization solution for this aspect of
>    IPP might work, and to relate these to the framework described in
>    [2].  This is not a product of the IPP working group, and is meant
>    only to illustrate some issues in authorization in order to establish
>    requirements for a "generic" protocol to support AAA functions across
>    many applications.
>
>    IPP print-by-reference allows a user to request a print service to
>    print a particular file.  The user creates a request to print a
>    particular file on a printer (or one of a group of printers).  The
>    key aspect is that the request includes only the file name and not
>    the file content. The print service must then read the file from a
>    file server prior to printing.  Both the file server and the print
>    server must authorize the request.  Once initiated, printing will be
>    done without intervention of the user; i.e., the file will be sent
>    directly to the print service rather than through the user to the
>    printer.
>
> 5.1.  Trust Relationships
>
>    The assumption is that the Printer and File Server may be owned and
>    operated by different organizations.  There appear to be two models
>    for how "agreements" can be set up.
>
>    1. User has agreement with Print Server; Print Server has agreement
>       with File Server.
>
>    2. User has agreements with both File and Print Server directly.
>
>    In case 1, the user has a trust relationship with the Print Service
>    AAA Server.  The Printer forwards the request to the File Server. The
>    File Server authorizes the Printer and determines if the Printer is
>    allowed access to the file.  Note that while there may be some cases
>    where a Print Server may on its own be allowed access to files
>    (perhaps some "public files", or that can only be printed on certain
>    "secure" printers), it is normally the case that files are associated
>    with users and not with printers.  This is not a good "generic" model
>    as it tends to make the print service an attractive point of attack.
>
>             +------+       +----------------------+
>             |      |       | File Service         |----+
>             |      |       | AAA Server           |<-+ |
>             |      |       +----------------------+  | |
>             |      |       |                      |  | |
>             |      |       | File Server          |  | |
>             |      |       |                      |  | |
>             | User |       +----------------------+  | |
>             |      |                                 | |
>             |      |                                 | |
>             |      |                                 | |
>             |      |       +----------------------+  | |
>             |      |------>| Print Service        |--+ |
>             |      |<------| AAA Server           |<---+
>             |      |       +----------------------+
>             |      |       | Print Server         |
>             |      |       |  and Printer         |
>             +------+       +----------------------+
>
>           Fig. 12 -- Case 1
>                      User authorizes with Print Service.
>                      Printer authorizes with File Service.
>
>    In case 2, the user must have a trust relationship with both the file
>    and print services so that each can verify the service appropriate to
>    the User.  In this case, the User first contacts the File Service AAA
>    Server and requests that it enable authorization for the Print
>    Service to access the file.  This might be done in various ways, for
>    example the File Service AAA Server may return a token to the User
>    which can (via the Print Service) be presented to the File Server to
>    enable access.
>
>                +------+       +----------------------+
>                |      |------>| File Service         |
>                |      |<------| AAA Server           |
>                |      |       +----------------------+
>                |      |
>                |      |       +----------------------+
>                |      |       | File Server          |
>                | User |       +----------------------+
>                |      |              /|\  |
>                |      |               |   |
>                |      |               |  \|/
>                |      |       +----------------------+
>                |      |------>| Print Service        |
>                |      |<------| AAA Server           |
>                |      |       +----------------------+
>                |      |       | Print Server         |
>                |      |       |  and Printer         |
>                +------+       +----------------------+
>
>          Fig. 13 -- Case 2
>                     User authorizes File and Print Service.
>                     Must create binding for session between
>                     Print Service and File Service.
>
> 5.2.  Use of Attribute Certificates in Print-by-Reference
>
>    The print-by-reference case provides a good example of the use of
>    attribute certificates as discussed in [2].  If we describe case 2
>    above in terms of attribute certificates (ACs) we get the diagram
>    shown in figure 14.
>
>
>       +------+       +----------------------+
>       |      |------>| File Service         |
>       |      |<------| AAA Server           |
>       |      |Get AC +----------------------+
>       |      |
>       |      |       +----------------------+
>       |      |       | File Server          |----+
>       |      |       |                      |<-+ |
>       | User |       +----------------------+  | |
>       |      |                                 | |
>       |      |   +---authorize passing AC      | |<---Create session
>       |      |   |                             | |    Using AC
>       |      |   V   +----------------------+  | |
>       |      |------>| Print Service        |  | |
>       |      |<------| AAA Server           |  | |
>       |      |       +----------------------+  | |
>       |      |       | Print Server         |--+ |
>       |      |       |  and Printer         |<---+
>       +------+       +----------------------+
>
>        Fig. 14 -- Using Attribute Certificates in IPP Authorization
>
>    In this case, the User gets an AC from the File Service's AAA Server
>    which is signed by the File Service AAA Server and contains a set of
>    attributes describing what the holder of the AC is allowed to do. The
>    User then authorizes with the Print Service AAA Server and passes the
>    AC in the authorization request.  The Printer establishes a session
>    with the File Server, passing it the AC.  The File Server trusts the
>    AC because it is signed by the File Service AAA Server and allows (or
>    disallows) the session.
>
>    It is interesting to note that an AC could also be created and signed
>    by the User, and passed from the Print Server to the File Server. The
>    File Server would need to be able to recognize the User's signature.
>    Yet another possibility is that the Print Service AAA Server could
>    simply authenticate the User and then request an AC from the File
>    Service AAA Server.
>
> 5.3.  IPP and the Authorization Descriptive Model
>
>    The descriptive model presented in [2] includes four basic elements:
>    User, User Home Organization, Service Provider AAA Server, and
>    Service Equipment.
>
>    Mapping these to IPP, the User is the same, the User Home
>    Organization (if included) is the same.  The Service Provider AAA
>    Server and the Service Equipment  are expected to be closely coupled
>    on the same processor.  In other words, the interface between the
>    Print Service AAA Server and the Printer as well as that between the
>    File Service AAA Server and the File Server is an internal one that
>    will not require a formal protocol (although some standard API might
>    be useful).
>
>    The concept of a Resource Manager (see [2]) has some interesting
>    twists relative to IPP.  Once started, the user is not involved in
>    the service, but until printing is complete it seems useful that any
>    of the parties in the authorization process be allowed to query for
>    status or to cancel the print session.   The user needs a way to
>    "bind" to a particular session, and may have to reauthorize to be
>    allowed to access Resource Manager information.
>
> ------------------------------------------------------------------------
>



More information about the Ipp mailing list