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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
