I'm thinking that in lieu of the registry, some amount of information could be stored directly in the encrypted ticket. Therefore, the validation process, through decryption, would expose the relevant data. And this could occur, without replication, on all CAS servers with the shared secret.
Of course, section 3.1.1 of the CAS protocol spec says: "Services MUST be able to accept service tickets of up to 32 characters in length. It is RECOMMENDED that services support service tickets of up to 256 characters in length." 32 characters, or even 256, may not be enough to encode (and encrypt) much info, for example, an entire proxy chain. But, perhaps it would be? Or maybe a limit of 512 is not infeasible? Minimally, I think the principal name could easily be encoded and encrypted in 256 characters. Locally, our use cases have not extended into the realm of proxy tickets. Currently, we are only using simple ST validation, so principal name is all we need. -Matt On Fri, 2007-10-12 at 09:38 -0500, Andrew R Feller wrote: > 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
