I wish I could make it -- but family conflicts don't allow for it this time. But, if anyone else feels the desire and ability to lead this discussion, I'd love to chat ahead of time to offer a few ideas!
-Matt -----Original Message----- From: Scott Battaglia [mailto:[EMAIL PROTECTED] Sent: Mon 2007-10-15 17:00 To: Smith, Matt; Yale CAS mailing list Subject: Re: CryptoTicket 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
