CryptoTicket

[Scott Battaglia]

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 <matt.smith at uconn.edu> 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
> matt.smith at uconn.edu
> University Information Technology Services (UITS)
> University of Connecticut
> PGP Public Key: http://web.uconn.edu/dotmatt/matt.asc
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
>


-- 
-Scott Battaglia

LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20071015/d0ed70e0/attachment.html