Good morning Matt, This is an interesting idea, which I believe has some merit. While reading through it, I was thinking how such a system would allow us to reduce traffic between CAS clients and the servers as clients wouldn't have to contact the server to see if a ticket is valid as it could decrypt it with a public key.
However, I am not seeing why you wouldn't need a ticket registry or replication. The reasons these exist are to contain information about tickets (tgt, st, pgt, pt) in a format that can be shared with other CAS servers and allow fail-over incase a CAS server needs to go down. I am interested in how your idea can provide the same features. Andrew R Feller, Analyst Subversion Administrator University Information Systems Louisiana State University [EMAIL PROTECTED] (office) 225.578.3737 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Smith, Matt Sent: Friday, October 12, 2007 9:10 AM To: Yale CAS mailing list Subject: CryptoTicket All- I've been mulling over the idea of implementing a "CryptoTicket" mechanism. I have not started coding, nor have any plans to do so in the immediate future, but wanted to start thinking about feasibility. Essentially, CryptoTickets are tickets (service tickets, proxy tickets, ticket granting tickets) whose validity can be verified algorithmically (via decryption), thereby not requiring storage. Additionally, these tickets would store (encrypted) the principal name and other relevant information internally, such that the validation process is reduced to decrypting the ticket and returning the stored information. Here are my thoughts: * A CryptoTicket avoids the need for ticket storage, and removes the requirement for registry replication in a clustered environment. Perhaps a CryptoTicketGrantingTicket (and CryptoTicketGrantingCookie?) could be used to avoid the need for session replication as well * CryptoTickets could allow a CryptoTicket-aware CAS client to perform service validation without a callback (assuming a shared secret, ala Kerberos). Other CAS clients, or clients requiring more than the simple principal (e.g., a SAML response) continue with the validation callback. * CryptoTickets violate section 3.1.1 of the CAS protocol specification: "Service tickets MUST only be valid for one ticket validation attempt." An embedded timestamp could lessen the security impact of this violation, but storage (and cluster replication) of used tickets would be necessary to fulfill the requirement. This could perhaps be implemented as a "CryptoTicketUnRegistry", and used only when determined necessary. Note the "Un" in "UnRegistry -- instead of storing (and replicating) valid tickets, this only stores and replicates consumed tickets. CAS clients could also implement a replay cache, (again, ala Kerberos) to counter ticket replay. Those are the basics. Can anyone tell me why this would be a bad idea to pursue? Or, has anyone already implemented something like this? Thanks all, -Matt -- Matt Smith [EMAIL PROTECTED] University Information Technology Services (UITS) University of Connecticut PGP Public Key: http://web.uconn.edu/dotmatt/matt.asc _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
