US006119230A
`6,119,230
`(114) Patent Number:
`United States Patent 55
`Carter
`[45] Date of Patent:
`Sep. 12, 2000
`
`
`[54] DISTRIBUTED DYNAMIC SECURITY
`CAPABILITIES
`Inventor: Stephen R. Carter, Spanish Fork, Utah
`[75]
`[73] Assignee: Novell, Inc., Provo, Utah
`
`[21] Appl. No.: 08/943,537
`.
`Oct. 1, 1997
`Filed:
`[22]
`Tints C0 i ceececccccccccccsssseecsessseeessssenseesssees GO06F 12/14
`[SL]
`[52] US. CD. i eecsscsscsssesssesseensecnsceneeeneesnennesee 713/200
`[58] Field of Search oe 713/200, 201,
`713/202, 161; 709/229; 380/3, 229, 4, 232,
`25, 30
`
`[56]
`
`:
`References Cited
`U.S. PATENT DOCUMENTS
`12/1985 Arnold et al.
`ccccccccccsccscssssssseeeeeees 380/4
`4,558,176
`
`. 235/382
`7/1986 Silvermanetal.
`4,599,509
`
`.......
`.. 340/825.3
`3/1993 Leith et al.
`5,196,840
`4/1993 Barlow ....
`.. 395/725
`5,204,961
`
`11/1993 Janis ...........
`... 395/725
`5,263,165
`
`+» 380/25
`5/1994 Abadiet al.
`5,315,657
`
`9/1994 Kingdon vessssessssssssssesseseensnee 380/25
`5,349,642
`1/1996 Hamilton et al. oe 395/700
`5,481,715
`2/1997 Blakley, III etal.
`. 340/825.31
`5,604,490
`
`.. 395/616
`7/1997 Miller et al.
`...
`5,649,194
`
`10/1998 Mashayekhi 380/25
`5,818,936
`6/1999 Higley et al. wee 713/201
`5,913,025
`FOREIGN PATENT DOCUMENTS
`
`0 695 985 Al
`
`.
`2/1996 European Pat. Off.
`OTHER PUBLICATIONS
`
`Syst
`
`Prentice Hall
`
`Sars, “The SSH Transport Layer Protocol”, Dr. Dobb’s
`Journal,(Oct. 1997), pp. 38-43.
`Tanenb
`Distributed Operating
`“es
`fremee
`Inc.(1995), p35463. peraing ystems,
`“Dover AFB employs Vigilant Networks with NDS™”,
`Electronic Government;Special Novell®Issue,pp. 12-13.
`Dalton et al., Windows NT Server4: Security, Troubleshoot-
`ing, and Optimization, New Riders Publishing (1996), pp.
`92-93. 371-75.
`Tanenbaum, Computer Networks, Third Edition, Prentice
`Hall, Inc. (1996), pp. 577-630.
`Grimes, Professional DCOM Programming, Wrox Press
`(1997), Ch. 7 pp. 319-389.
`Lampson et al., “Authentication in Distributed Systems:
`Theory and Practice”, ACM Transaction on Computer Sys-
`tems,vol. 10, No. 4 (Nov. 1992), pp. 265-310.
`“DCE web and Security Domains”, no later than May 16,
`«1997.
`Steve Lewontin, “The DCE—Web: Securing the Enterprises
`Web”. Nov. 1995.
`,
`“Secure Web—Architecture”, no later than May 16, 1997.
`“Secure Web Architecture—Scalability”, no later than May
`16 1997
`:
`:
`>
`“DCE Web Security”, no later than May 16, 1997.
`:
`“Da.
`5s
`39
`Rich Salz,
`“Re: [QJDCE RPC Encription”, Jul. 21, 1995.
`
`Primary Examiner—Robert W. Beausoliel, Jr.
`Assistant Examiner—Pierre Eddy Elisca
`Attorney, Agent, or Firm—Computer Law++
`
`[57]
`
`ABSTRACT
`
`Methods and systems are provided for managing security
`credentials in a distributed computer system. Multiple secu-
`rity contexts may be defined for a given principal in the
`system without requiring the use of multiple accounts. A
`secure package is provided to allow the principal to roam.
`Methods are provided for identifying differences in the
`principal’s access nights in different contexts and for updat-
`ing the secure package as needed.
`
`Lampson et al., Abstract—‘“Authentication in distributed
`systems:theory and practice” , ACM Transaction on Com-
`puter Systems,vol. 10, No. 4 (Nov. 1992), pp. 265-310.
`Jurec et al., Abstract—“Exchangeof patient records—proto-
`type implementation of a security attributes service in
`X.500”, Proceedings of the 2ACM Conference on Computer
`and Communications Security,pp. 30-38.
`Chaum, Abstract—“Security without identification:transac-
`tion systems to make big brother obsolete”, Communica-
`tions of the ACM,vol. 28, No. (Oct. 1985) pp. 1030-1044.
`45 Claims, 3 Drawing Sheets
`
`— 400
`PROVIDE SECURE PACKAGE
`402
`IDENTIFY/AUTHENTICATE
`404
`SIGN
`406
`ENCRYPT
`408
`STORE
`410
`
` ——————| +
`
`
`—~ 412
`REQUEST ACCESS
`tA
`REQUESTINFO. ABOUT SYSTEM
`418 420
`REQUEST FORWARDING
`
` NOTIFY
`422 +
`ENABLE CREDENTIAL CHECK
`424
` ALLOW OR DENY REQUEST
`426
`——
`DETERMINE CONTEXTUAL
`428 DIFFERENCESIN CREDENTIALS
`
`IDENTITY
`
`
`— 430
`MODIFY SECURE PACKAGE
`432
`434
`MODIFY SIGNATURE(S)
` ADD/REMOVE ACCESS RIGHT(S)
`
`436
`
`
`ADD/REMOVE CREDENTIAL(S)
`416 REQUEST ACCESS TO RESOURCE
`
`VERIFY
`
`J
`
`INTEL Ex. 1261.001
`
`INTEL Ex. 1261.001
`
`

`

`U.S. Patent
`
`Sep. 12, 2000
`
`Sheet 1 of 3
`
`6,119,230
`
`-— 120
`
`S
`aL
`S
`
`106,
`
`CI
`
`110
`Z
`iL
`II —-
`
`104
`
`ms
`NETWORKS
`
`102
`
`110,
`116
`
`vo,=(OD
`
`112 ed
`
`114
`
`110
`
`110,
`
`INTEL Ex. 1261.002
`
`INTEL Ex. 1261.002
`
`

`

`U.S. Patent
`
`Sep. 12, 2000
`
`Sheet 2 of 3
`
`6,119,230
`
`
`
`FIG. 2
`
`SECURE PACKAGE
`DIGITAL SIGNATURE
`PRINCIPAL IDENTIFICATION
`
`DIGITAL SIGNATURE
`
`300
`302
`|] 306
`
`3081 310
`
`DIGITAL SIGNATURE
`
`DIGITAL SIGNATURE
`
`DIGITAL SIGNATURE
`
`312
`314
`
`316
`
`FIG. 3
`
`INTEL Ex. 1261.003
`
`INTEL Ex. 1261.003
`
`

`

`U.S. Patent
`
`Sep. 12, 2000
`
`Sheet 3 of 3
`
`6,119,230
`
`
`PROVIDE SECURE PACKAGE
`402
`IDENTIFY/AUTHENTICATE
`404
`
`400
`
`
`
`412
`
`
`REQUEST ACCESS TO RESOURCE
`
`REQUEST FORWARDING
`
`
`
`
`
`
`
`
`
` 430
`
`
`
`
`432
`MODIFY SIGNATURE(S)
`ADD/REMOVE CREDENTIAL(S)
`
`
`ADD/REMOVE ACCESSRIGHT(S)
`
`
`ENCRYPT
`
`REQUEST ACCESS
`REQUEST INFO ABOUT SYSTEM
`
`NOTIFY
`
`428
`
`VERIFY
`IDENTITY
`
`
`
`ENABLE CREDENTIAL CHECK
`
`ALLOW OR DENY REQUEST
`
`
`DETERMINE CONTEXTUAL
`DIFFERENCES IN CREDENTIALS
`
`MODIFY SECURE PACKAGE
`
`406
`408
`
`414
`416
`
`418
`
`422
`
`424
`
`426
`
`434
`
`436
`
`FIG. 4
`
`INTEL Ex. 1261.004
`
`INTEL Ex. 1261.004
`
`

`

`6,119,230
`
`1
`DISTRIBUTED DYNAMIC SECURITY
`CAPABILITIES
`
`FIELD OF THE INVENTION
`
`invention relates to security in computer
`The present
`systems, and more particularly to a system and method for
`issuing a secure package of credentials to a user or agent,
`providing different access capabilities at different system
`locations based in part on the secure package, and modifying
`the secure package to reflect local information about the
`access capabilities of the user or agent.
`TECHNICAL BACKGROUND OF THE
`INVENTION
`
`10
`
`15
`
`20
`
`25
`
`30
`
`40
`
`45
`
`50
`
`55
`
`60
`
`Uniformity of access rights simplifies the implementation
`of authentication methods, but
`in some situations more
`flexibility would be beneficial. For instance, a distributed
`system might contain both a home domain anda directory
`
`65
`
`Various approaches have been proposed and/or imple-
`mented to support roaming users and roaming machines in
`distributed computer systems. One approach, which is
`implemented in Novell NetWare 4.1 and later versions and
`in Novell NDS software, allows users to gain access to
`multiple servers in a distributed directory tree without
`logging in and authenticating themselves to each server
`individually (NOVELL, NETWARE,and NDSare marks of
`Novell, Inc.). However, a separate account, and separate
`login and authentication processes, are still required before
`The present invention provides a method and system for
`a user can login to a computer which is not part of the
`managing security credentials in a distributed system where
`distributed directory tree, even if that computer is in network
`different locations in the system may contain different infor-
`communication with a computer whichis part of the tree.
`mation abouta principal’s accessrights. In one embodiment,
`the system is assumed to have a credential checking facility
`An other approach, which involves home domains and
`to authenticate one or more principals. A principal may be a
`logon certificates, is described in European Patent Applica-
`human user. The principal may also be an agent such as a
`tion EP 0 695 985 Al, having priority based on US.
`application Ser. No. 277,144 filed Jul. 18, 1994 (“Logon
`user’s avatar or a system maintenance process or an infor-
`Certificates Applications”),
`incorporated herein by refer-
`mation gathering “spider”.
`ence. Logoncertificates support disconnected operation in a
`A method of the invention starts by providing the prin-
`35
`distributed system. Each logon certificate is a secure pack-
`cipal with a secure packageinafirst directory context. The
`age holding credentials information sufficient to establish
`secure packageis provided by storing its contents in a buffer.
`the identity and access rights of a principal (a user or a
`Suitable buffers include RAM, floppy disks, hard disks,
`machine) in a domain other than the principal’s home
`portable computers, hard tokens, removable storage media,
`and combinations of these individual buffers. The secure
`domain. Access is enforced through means such as encryp-
`tion and digital signatures. Logon certificates can be carried
`by the principal in convenient forms such as on a portable
`machine or on a floppy disk.
`The relationship between a home domain anda distrib-
`uted directory tree is not clear from the Logon Certificates
`Applications. The use of logon certificates is presented in the
`Logon Certificates Applications as an alternative to repli-
`cating credentials. Although credentials may be replicated in
`a distributed directory tree, however, replication is not
`required. More generally, domains and distributed directory
`trees differ in the services they provide, the hardware and
`software they require or allow, and in characteristics such as
`scalability and fault-tolerance.
`However, a home domain and a distributed directory tree
`each define a context throughout which a given principal has
`identical access rights. Regardless of the location in the
`distributed directory tree at which the principal accesses the
`system, the principal has the same access rights. Similarly,
`a principal has the same access rights regardless of which
`location in the home domain is used to access the system.
`Indeed,
`if logon certificates are used,
`the principal will
`receive the same access rights regardless of whether the
`access attempt occurs inside the principal’s home domain or
`outside that domain.
`
`2
`tree, with each defining a given principal’s access rights
`differently. It would be useful to provide the principal with
`a straightforward (from the principal’s point of view) way to
`logon and use machines in the domain, machines in the
`directory tree, or both. Supporting different access rights for
`a given principal would also reduce the need to rapidly
`propagate changes to maintain uniform rights,
`thereby
`reducing the burden on domain controllers and directory tree
`administrators. However, such advances would require a
`distributed system that functions properly when different
`parts of the system have different access rights for a given
`principal, without using separate accounts.
`Thus, it would be an advancementin the art to support
`multiple simultaneous access right contexts for a single
`principal in a distributed system.
`It would be an additional advancementto provide such a
`method and system which is a compatible extension of
`known distributed directory tree and logon certificate
`approaches.
`Such a method and system are disclosed and claimed
`herein.
`
`BRIEF SUMMARY OF THE INVENTION
`
`package contains information identifying the principal and
`also contains zero or more security credentials of the prin-
`cipal. The package has beenatleast partially encrypted or
`digitally signed or otherwise secured to discourage unau-
`thorized disclosure or modification of the package contents.
`A “directory context” is a portion of the system throughout
`which the principal has identical access rights. A home
`domain is one of many possible examples of a directory
`context.
`
`In a second directory context, the system receives an
`access request from the principal. The request may seek
`information about the system, access to information or other
`resources within the system, or use of the system to forward
`a message. The credential checking facility checks the
`access request by accessing the credentials in the secure
`package and comparing them with the system’s internal
`security records. The system then allowsor denies the access
`request according to the result of the credential check.
`The system also determines whether credential informa-
`tion about
`the principal which is found in the second
`directory context was not placed in the secure packagein the
`first directory context. If differences exist, the secure pack-
`age may be modified to reflect the differences. Modification
`may involve digitally signing at least a portion of the secure
`package, such as principal identifying information and/or
`credentials in the secure package. Digital signatures,
`credentials, access rights, identifying information, and other
`information may be replaced, removed, or added. One
`
`INTEL Ex. 1261.005
`
`INTEL Ex. 1261.005
`
`

`

`6,119,230
`
`3
`method requires further verification of the principal’s iden-
`tity before modifying the secure package, such as by using
`an identification means that was not used inthe first direc-
`
`tory context when the secure package was previously pro-
`vided.
`
`4
`bination thereof. The network may include one or more
`LANs, wide-area networks, Internet servers and clients,
`intranet servers and clients, peer-to-peer nodes, network
`operating servers and clients, or a combination thereof.
`A portion of one of the computer systems 100 suited for
`use with the present invention is shown in FIG. 1. In one
`Acomputer system according to the invention contains a
`embodiment,
`the system 100 includes Novell NetWare®
`first directory context includingafirst set of credentials of a
`network operating system software (NETWAREis a regis-
`principal and also including a providing meansfor providing
`tered trademark of Novell, Inc.) and Novell Directory Ser-
`the principal with a secure package containing at least part
`vices software. In alternative embodiments, the system 100
`of the first set of credentials. The system also contains a
`includes NetWare Connect Services, VINES, TCP/IP, IPX,
`second directory context including a second set of creden-
`Windows NT, Windows 95, LAN Manager, and/or LANtas-
`tials of the principal and also including a modifying means
`tic network operating system software and/or an implemen-
`for modifying the secure package to reflect differences
`tation of a distributed hierarchical partitioned object data-
`between credentials in the second set and credentials which
`base according to the X.500 protocol or another directory
`were placed in the secure package by the providing means
`service protocol such as the Lightweight Directory Access
`of the first directory context.
`Protocol (VINESis a trademark of Banyan Systems; NT,
`The directory contexts may be defined at least in part
`WINDOWS95, and LAN MANAGERare trademarks of
`according to a hierarchy or a connected graph of clearance
`Microsoft Corporation; LANTASTIC is a trademark of
`levels and classification levels. A directory context may
`Artisoft). The system 100 may include a local area network
`include a home domain of the principal and/or locationsthat
`102 which is connectable to other networks 104, including
`are connected within a distributed directory such as an NDS
`other LANsorportions of the Internetor an intranet, through
`tree. A location in the first directory context may be con-
`a gateway or similar mechanism.
`nected bythe distributed directory to a location in the second
`The system 100 includes several servers 106 that are
`directory context. The first context may include a first
`connected by network signal
`lines 108 to one or more
`computer while the second context
`includes a different,
`network clients 110. The servers 106 and network clients
`second computer; the two computers may be networked, or
`110 may be configured by those of skill in the art in a wide
`they may include standalone or mobile disconnectable
`variety of ways to operate according to the present inven-
`machines. Alternatively, both contexts may be defined on the
`tion. The servers 106 may be configured as Internet servers,
`same computer at different times.
`as intranet servers, as general file and print servers, as
`Unlike other approaches, the invention allows multiple
`directory service providers, as name servers, as software
`security contexts to be defined for a given principal in the
`componentservers, or as a combination thereof. The servers
`system without requiring the use of multiple accounts, while
`106 may be uniprocessor, multiprocessor, or clustered pro-
`cessor machines. The servers 106 and clients 110 each
`still allowing the principal
`to roam. Other features and
`advantages of the present invention will become morefully
`apparent through the following description.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`To illustrate the manner in which the advantages and
`features of the invention are obtained, a more particular
`description of the invention will be given with reference to
`the attached drawings. These drawings only illustrate
`selected aspects of the invention and thus do not limit the
`invention’s scope. In the drawings:
`FIG. 1 is a diagram illustrating part of a computer system
`which is one of the many systems suitable for use with the
`present invention.
`FIG. 2 is a diagram further illustrating the computer
`system of FIG. 1.
`FIG. 3 is a block diagram illustrating a secure package of
`credentials according to the present invention.
`FIG. 4 is a flowchart illustrating methods of the present
`invention.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`The present invention relates to a method and system for
`managing security credentials in a distributed system. The
`invention may be used with local area networks, wide area
`networks, and/or the Internet. “Internet” as used herein
`includes variations such as a private Internet, a secure
`Internet, a value-added network, a virtual private network,
`an extranet, or an intranet. The computers connected by the
`network may be workstations, laptop computers, discon-
`nectable mobile computers, servers, mainframes, so-called
`“network computers”, personal digital assistants, or a com-
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`include an addressable storage medium such as random
`access memoryand/or a non-volatile storage medium such
`as a magnetic or optical disk.
`Suitable network clients 110 include, without limitation,
`personal computers 112, laptops 114, workstations 116, and
`dumb terminals. The signal lines 108 may include twisted
`pair, coaxial, or optical
`fiber cables,
`telephone lines,
`satellites, microwave relays, modulated AC powerlines,
`and/or other data transmission “wires” known to those of
`skill in the art. In addition to the network client computers
`110, a printer 118 and an array of disks or other persistent
`storage 120 are also attached to the system 100. A given
`computer may function both as a client 110 and as a server
`106;
`this may occur, for instance, on computers running
`Microsoft Windows NT software. Although particular indi-
`vidual and network computer systems and components are
`shown,
`those of skill in the art will appreciate that the
`present invention also works with a variety of other net-
`works and computers.
`The servers 106 and the network clients 110 are capable
`of using floppy drives, tape drives, optical drives or other
`means to read a storage medium 122. A suitable storage
`medium 122 includes a magnetic, optical, or other
`computer-readable storage device having a specific physical
`configuration. Suitable storage devices include floppy disks,
`hard disks,
`tape, CD-ROMs, PROMs,
`random access
`memory, and other computer system storage devices. The
`physical configuration represents data and instructions
`which cause the computer system to operate in a specific and
`predefined manner as described herein. Thus, the medium
`122 tangibly embodies a program, functions, and/or instruc-
`tions that are executable by the servers 106 and/or network
`client computers 110 to perform credential management
`
`INTEL Ex. 1261.006
`
`INTEL Ex. 1261.006
`
`

`

`6,119,230
`
`5
`substantially as described herein. Suitable software for
`implementing the invention is readily provided by those of
`skill
`in the art using the teachings presented here and
`programming languages such as Java, Pascal, C++, C,
`assembly, firmware, microcode, and/or other languages.
`FIG. 2 furtherillustrates the system 100. The system 100
`includes a home domain 200 of a principal, a distributed
`directory tree 202, a gateway 204 connecting the home
`domain 200 with the directory tree 202, and a standalone
`computer 206. Any one or more of these components may be
`omitted in other systems configured according to the inven-
`tion. A system need only contain one or more computers
`which hold information and/or other resources to which
`access is restricted. The computers may be standalone
`computers, networked computers, mobile computers which
`are connectable to a network, or a combination of such
`computers. The principal may be a humanuser, a software
`agent, or a hardware agent which seeks access to the system
`or system resources.
`The home domain 200 includes a domain controller 208
`
`and other computers 210. The domain 200 maybe config-
`ured using software such as Microsoft Windows NTsoft-
`ware (marks of Microsoft Corporation) and/or software and
`hardware described in the Logon Certificates Applications,
`incorporated herein by reference.
`The distributed directory tree 202 includes a master server
`212 and other computers 214. The directory tree may be
`configured using software such as Novell Directory Services
`and Novell NetWare software (marks of Novell, Inc.) and/or
`other database, object database, hierarchical database, hier-
`archical object database, relational database, transactional
`system, X.500, networking, or directory services software.
`In a conventionally configured system, the home domain
`200 and the directory tree 202 would each define a context
`within which the principal has uniform access rights. When
`the system 100 is configured according to the present
`invention, each of the contexts 200, 202 maystill be defined.
`However, with the invention other context definitions are
`also possible.
`The invention supports flexible definition of one or more
`contexts for a given principal in a distributed system without
`requiring multiple accounts. A “directory context” is a
`portion of a system throughout which a given principal has
`identical access rights. Access to the system may be
`attempted at different locations in a single directory context,
`or at different locations in different directory contexts. Two
`attempted accesses lie within the same directory context if
`they are made by the same principal and if the principal’s
`credentials are the same for each attempted access. A given
`computer may be part of more than one directory context,
`and a given directory context may include one or more
`computers.
`For instance, after the system 100 is configured according
`to the invention, any of the following directory context
`definitions could be made:
`
`EXAMPLE1
`
`Context A: home domain 200
`
`Context B: directory tree 202
`Context C: standalone machine 206
`
`EXAMPLE 2
`
`Context A: domain controller 210, master server 212, and
`gateway 204
`Context B: machines 210, 214
`
`6
`EXAMPLE 3
`
`wn
`
`10
`
`15
`
`20
`
`25
`
`40
`
`55
`
`60
`
`65
`
`Context A: home domain 200 and directory tree 202
`Context B: standalone machine 206
`Those of skill in the art will appreciate that numerous
`other directory context definitions are also possible. For
`instance, contexts could be defined according to rings,
`levels,
`layers, zones, or other paradigms. Moreover,
`the
`directory context definition may change over time, without
`direct administrator intervention, because the present inven-
`tion allows modification of the secure package to reflect
`differences in access rights at different
`locations in the
`system.
`FIG. 3 illustrates one embodiment of a secure package
`300 according to the present invention. The secure package
`300 includes a digital signature 302, created using means
`described in the Logon Certificates Applications or other
`means familiar to those of skill
`in the art. The digital
`signature 302 may apply to part orall of the secure package
`300. In particular, the secure package 300 may contain one
`or more credentials to which the digital signature 302 does
`not apply. The digital signature 302 discourages tampering
`with the contents of the secure package 300 by making it
`possible to detect unauthorized changes to those contents.
`Multiple digital signatures may also be used.
`In some embodiments, secure packages according to the
`invention are encrypted using symmetric or asymmetric
`encryption algorithms such as those described in the Logon
`Certificates Applications or other encryption means familiar
`to those of skill in the art. In some embodiments,the digital
`signature 302 for the overall secure package is omitted, and
`security 1s provided instead through encryption and/or digi-
`tal signatures on one or more portions of the secure package.
`The secure package 300 also includes a principal identi-
`fication 304 which identifies the principal whose credentials
`will be managed using the secure package 300. A given user
`or agent may have more than one principal identification
`304, and a given principal identification 304 may identify
`morethan oneuser or agent. The principalidentification 304
`is not
`the equivalent of an account
`identification in a
`conventional system. A conventional account provides only
`one context, but the invention allows users to have different
`access rights associated with a single principal identification
`304, depending onthe current directory context of the secure
`package 300.
`The principal identification 304 maybe signed by a digital
`signature 306, may be signed by multiple digital signatures,
`or may be unsigned. The principal identification 304 may
`also be encrypted, or it may be both signed and encrypted.
`Each secure package includes zero or more security
`credentials for the principal. The illustrated secure package
`300 includes a first credential 308 signed by a digital
`signature 310, as well as a second credential 312 which is
`signed by two digital signatures 314 and 316. In alternative
`embodiments, each credential in a secure package may be
`signed by zero or more digital signatures, may be encrypted,
`or may be both signed and encrypted.
`Each credential 308, 312 includes a description of the
`principal’s access rights. Access right descriptions may
`include tokens, keys, group identifiers, access controllists,
`permissions, certificates, and other descriptions known to
`those of skill in the art. The access rights granted or denied
`or constrained may concern operations such as reading,
`writing, deleting, renaming, modifying security parameters,
`and other operations on computer systems and their
`resources.
`
`The validity of a credential may be confirmed or denied
`during an authentication process. The system 100 includes a
`
`INTEL Ex. 1261.007
`
`INTEL Ex. 1261.007
`
`

`

`6,119,230
`
`8
`Once the principal receives the secure package 300, the
`principal(orits authorized substitutes) can use the package
`300 to facilitate authentication at different locations in the
`
`7
`credential checking facility to authenticate principals by
`checking the validity of the credentials they present. Authen-
`tication may involve decrypting part or all of the secure
`package 300, recalculating a digital signature on partorall
`of the secure package 300 and comparing it to the corre-
`sponding digital signature 302, 306, 310, 314, 316 and so
`forth presented in the package 300, requiring further iden-
`tification from the principal, and/or taking other steps to
`confirm the validity of the credentials and/or the right of the
`principal to those credentials. Many suitable authentication
`methods and mechanismsare knownto those of skill in the
`art.
`
`system 100 and to managethe access rights and credentials
`associated with those locations, without direct intervention
`by a system administrator.
`The principal may login to the system 100 during an
`optional step 410, but access requests may also be made
`during a step 412 without logging in. The principal may
`already be logged in, or the principal may be permitted to
`skip login if the principal indicates it has a secure package
`300 containing at least the information that would be gained
`FIG. 4 illustrates a method of the present invention for
`by the login step 410.
`managing credentials in a system such as the system 100
`Requests made during the step 412 may seek different
`using secure packages such as the secure package 300.
`types of access. During a step 414, the principal may request
`During a providing step 400, the system 100 provides the
`information about use of the system 100, such as the name
`principal with the secure package 300. For purposes of
`and email address of an administrator, the clearance level
`discussion, assume the secure package 300 containsat least
`required at this location by the system 100, or an address for
`one credential 308. In other situations the system 100 may
`connection to the system 100 (IP address, port number,
`provide a secure package 300 containing zero credentials,
`socket number, direct dial modem number, et cetera).
`thereby granting no access rights or granting only minimal
`During a step 416, the principal may request access to a
`default rights, according to the system’s configuration.
`resource on the system 100, such as file contents, object
`Before providing the secure package 300, the system 100
`attribute values, or a list of current users. A request to
`typically performs an identification/authentication step 402
`execute a program,
`task,
`thread, or other computerized
`to ensure the identity of the principal and/or verify the
`process is also an access request, since the execution
`principal’s claim to the credentials. Conventional identifi-
`requires processor time, memory, and possibly other system
`cation methods and mechanisms maybe used, such as those
`resources. In particular, during a step 418, the principal may
`involving passwords, magnetic cards,retinal scans, physical
`
`or digital keys, and the like. Conventional authentication request execution of processes which will forwardafile,
`methods and mechanisms may also be used.
`packet, message, or other data to another location in the
`During an optional signing step 404, the secure package
`system 100 or to a destination outside the system 100.
`300 or a portion thereof, such as the principal identification
`An access monitoring agent or a system administrator
`304 and/orthe credential 308, may be digitally signed. Many
`may be notified about the access request during an optional
`suitable digital signature methods are available to those of
`step 420. This may be done to detect unauthorized access
`skill
`in the art,
`including those discussed in the Logon
`attempts, to log access requests for possible later inspection,
`Certificates Applications incorporated herein.
`or merely to track system usage for accounting purposes.
`During an optional encrypting step 406, the secure pack-
`During an enabling step 422,
`the credential checking
`age 300 or a portion thereof, such as the principal identifi-
`facility of the system 100 is enabled to check the access
`cation 304 and/or the credential 308, may be digitally
`request by accessing the credentials in the secure package
`signed. Many suitable encryption methodsare available to
`300. This may involve decrypting part of all of the secure
`those of skill in the art, including those discussed in the
`package 300, recalculating one or more digital signatures
`Logon Certificates Applications incorporated herein. Differ-
`based onpart or all of the secure package 300 and comparing
`ent portions of the secure package 300 may be encrypted
`the results with the digital signatures contained in the secure
`using different encryption methods. For instance, a fast
`package 300, and/or comparing information in the secure
`symmetric algorithm could be used in conjunction with a
`package 300 with information in a secure user database.
`slower but more secure asymmetric algorithm. Likewise,
`During a step 424, the system 100 either allows or denies
`different portions of the secure package 300 may be
`the access request, based on the result of the credential
`encrypted using different key lengths. The signing step 404
`check. If the principal’s request is authenticated by the
`may precede or follow the encrypting step 406.
`credentials in the secure package 300, the request is allowed
`Moregenerally, the steps illustrated and discussed herein
`and access is granted. Otherwise, access may be denied
`may be performed in various orders, except in those cases in
`outright, or the principal may be given an opportunity to
`whichthe results of one step are required as input to another
`authenticate by alternative means such as a conventional
`step. Likewise, steps may be omitted unless called for in the
`login and authentication process. Limited access may also
`be allowed. For instance,
`if the credentials would have
`claims, regardless of whetherthey are expressly described as
`optional in this specification. Steps may also be repeated, as
`validated a read request but the request actually sought write
`55
`
`whenacredential is signed, encrypted, and signed again. access, then read-only access could be allowed.
`During a storing step 408, the secure pac