Matt, If you're coming to the JA-SIG UnConference, this would be a great topic to discuss (pros/cons/implications), what protocols do something similar (Open ID has some similarities to what you propose), etc.
-Scott On 10/12/07, Smith, Matt <[EMAIL PROTECTED]> wrote: > > 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 > > > -- -Scott Battaglia LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
