IPP Mail Archive: RE: IPP> IPP Authorization Models - excerp

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

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Oct 02 2000 - 17:46:55 EDT

  • Next message: McDonald, Ira: "IPP> RFC 2910/2911 - IPP 1.1 Proposed Std (2 October 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@manros.com]
    Sent: Monday, October 02, 2000 12:49 PM
    To: McDonald, Ira; ipp@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@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of McDonald,
    > Ira
    > Sent: Monday, October 02, 2000 11:52 AM
    > To: 'ipp@pwg.org'
    > Subject: IPP> IPP Authorization Models - excerpt from RFC 2905 - please
    > review
    >
    >
    > Copies: IETF IPP WG <ipp@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.
    >
    > ------------------------------------------------------------------------
    >



    This archive was generated by hypermail 2b29 : Mon Oct 02 2000 - 17:56:28 EDT