DOC PREVIEW
WUSTL CSE 571S - Kerberos V5

This preview shows page 1-2-24-25 out of 25 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

11-1©2007 Raj JainCSE571SWashington University in St. LouisKerberos V5Kerberos V5Raj Jain Washington University in Saint LouisSaint Louis, MO [email protected]/Video recordings of this lecture are available at:http://www.cse.wustl.edu/~jain/cse571-07/11-2©2007 Raj JainCSE571SWashington University in St. LouisOverviewOverview! Kerberos V4 Issues! ASN.1 and BER! Names, Delegation of Rights! Ticket Lifetimes! Cryptographic Algorithms! Hierarchy of Realms11-3©2007 Raj JainCSE571SWashington University in St. LouisKerberos V4 IssuesKerberos V4 Issues1. Names, Instance, Realm (non standard)1. Only DES encryption2. Only IPv4 addresses3. Byte ordering indicated in the message (ASN.1 better)4. Maximum life time limited to 21 hours: 8 bit life time in units of 5 minutes5. No delegation6. Inter-realm authentication limited to pairs ⇒ N2pairs7. Double encryption of the ticket: Kclient[Kserver[...]]8. PCBC does not detect interchange of cipher blocks9. No subsession keys for long sessions10. Brute force password attack11-4©2007 Raj JainCSE571SWashington University in St. LouisASN.1ASN.1! Abstract Syntax Notation One! Joint ISO and ITU-T standard, Original 1984, latest 2002.! Used to specify protocol data structures! X.400 electronic mail, X.500 and LDAP directory services, H.323 VOIP, SNMP, etc use ASN.1! Pre-Defined: INTEGER, BOOLEAN, BIT STRING, OCTET STRING! Constructed: SEQUENCE (structure), SEQUENCE OF (lists), CHOICE, ...11-5©2007 Raj JainCSE571SWashington University in St. LouisASN.1 ExampleASN.1 ExampleAddressType ::= SEQUENCE {name OCTET STRING,number INTEGER,street OCTET STRING,city OCTET STRING,state OCTET STRING,zipCode INTEGER}11-6©2007 Raj JainCSE571SWashington University in St. LouisEncoding RulesEncoding Rules! ASN.1 only specifies the structure.! Encoding rules indicate how to encode the structure in to bits on the wire.! Examples: Basic Encoding Rules (BER), Packed Encoding Rules (PER), XML Encoding rules (XER), Distinguished Encoding Rules (DER), ...! In BER, everything is encoded as Tag-Length-Value.11-7©2007 Raj JainCSE571SWashington University in St. LouisBER ExampleBER Example! John Miller, 126 Main Street, Big City, MO 6313030 80 04 0B 4A 6F 68 6E 20 4D 69 6C 6C 65 72Seq. Len Oct Str Len J o h n M i l l e r02 01 FEInt Len 12304 0B 4D 61 69 6E 20 53 74 72 65 65 74Oct str 11 M a i n S t r e e t04 08 42 69 67 20 43 69 74 79Oct Str Len B i g C i t y04 02 4D 4F 02 02 F6 96 0Oct Str Len M O Int len 63130 Null11-8©2007 Raj JainCSE571SWashington University in St. LouisNamesNames! V4: Name, Instance, Realm (40 character each. Null terminated). Dot "." is illegal.! V5: Name can contain dot and can have many parts., e.g., jain.raj! V4: Realms are DNS names.! V5: Realms can be DNS names, X.500 names, etc11-9©2007 Raj JainCSE571SWashington University in St. LouisDelegation of RightsDelegation of Rights! Need: Backup job requires operators to access files! V5 allows requesting a TGT with a different address ! Can include many addresses or no addresses ⇒ Anyone.! TGT with operator's address can then be passed to the operator.! Can also request to include application specific restrictions inthe TGT! These restrictions are copied in the tickets! Can request that TGT be forwardable ⇒ One operator can pass it to another operator.! Can request that TGT be proxiable ⇒ Alice can request a ticket from TGT for use by the operator.! Allowing delegation, forwarding, proxy, many addresses, no addresses are policy decisions11-10©2007 Raj JainCSE571SWashington University in St. LouisTicket LifetimesTicket Lifetimes! V4: Lifetime is one octet ⇒ max 256 in units of 5 minutes ⇒ Max 21 hours! V5: Many timestamps, each in ASN.1 format (17 bytes in s)! Start Time! End Time! Auth Time: Time at which initial TGT was obtained! Renew Till: Must renew after this time! Start Time < End Time < Renew Till11-11©2007 Raj JainCSE571SWashington University in St. LouisRenewable TicketsRenewable Tickets! Tickets cannot be invalidated! Long term use permitted only if renewed frequently! Expired tickets cannot be renewed⇒ KDC does not have to remember revoked tickets for long time11-12©2007 Raj JainCSE571SWashington University in St. LouisPostdated TicketsPostdated Tickets! Start Time in future! Pre-invalidated ⇒ Must be validated at the start time⇒ Allows revoking the authentication! May-Postdate flag in TGT ⇒ TGS can issue post-dated tickets11-13©2007 Raj JainCSE571SWashington University in St. LouisKey VersionsKey Versions! Allows principals to change keys! Multiple versions of keys are kept at KDC and TGS! Each key is stored as <Key, Principal_KeyVersionNo, KDC_KeyVersionNo>⇒ Allows the possibility of KDC changing its key! Helpful for renewable and post-dated tickets! Renewal Tickets are issued with the latest keys11-14©2007 Raj JainCSE571SWashington University in St. LouisMaster Keys in Different RealmsMaster Keys in Different Realms! Password-to-key hash function uses realm name also! Attacker cannot use the same key in multiple realms(Attacker can still use the same password in multiple realms)11-15©2007 Raj JainCSE571SWashington University in St. LouisOptimizationsOptimizations! V4: Ticket is encrypted with client's keyTicket is already encrypted with Server's key ⇒ Double encryption! V5: Ticket is not encrypted again! V4: Target's name inside the ticket! V5: No name inside the ticket11-16©2007 Raj JainCSE571SWashington University in St. LouisCryptographic AlgorithmsCryptographic Algorithms! V4: DES! V5: Encryption field is type-value encoded ⇒ Any encryption11-17©2007 Raj JainCSE571SWashington University in St. LouisIntegrityIntegrity--Only AlgorithmOnly Algorithm! V4: Jueneman Checksum! V5: Choice of algorithms" rsa-md5-des" des-mac" des-mac-k" res-md4-des (optional)" rsa-md4-des-k (Optional)11-18©2007 Raj JainCSE571SWashington University in St. LouisEncryption for Privacy and IntegrityEncryption for Privacy and Integrity! Choice: des-cbc-crc, des-cbc-md4, des-cbc-md5! Checksum is combined with the message and then encrypted with DES in CBC mode.11-19©2007 Raj JainCSE571SWashington University in St. LouisHierarchy of RealmsHierarchy of Realms! V4: Limits to pairs! V5: Transition allowed.! B is registered with A and C is registered with B! x@A can get to y@C via B! List of all transited KDC's is put in the ticket! It is the applications responsibility to decide if some transited KDC is trustworthyABCDEFG11-20©2007 Raj JainCSE571SWashington University in


View Full Document

WUSTL CSE 571S - Kerberos V5

Documents in this Course
IP sec

IP sec

28 pages

Load more
Download Kerberos V5
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Kerberos V5 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Kerberos V5 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?