Kerberos4(NSchapter13) - PowerPoint PPT Presentation

� Kerberos�4�(NS�chapter�13)� � � ���������������������������������� � • Realm�has�KDC�and�principals�(users)� Computer�and�Network�Security� • Users�are�humans�and�(distributed)�applications�(NFS,�rsh,�etc)� CMSC�414� • Human�users�log�in�to�workstations,�use�applications�(apps)� � • Apps�can�interact�with�other�apps�(eg,�ftp�with�NFS)� STANDARDS� • KDC�authenticates�login�sessions�and�apps� • Based�on�Needham2Schroeder�authentication�protocol.� � • Assumes�attacker�can�eavesdrop�and�modify�messages�in�transit.� Udaya�Shankar� • Assumes�DES�and�IPv4� shankar@cs.umd.edu� • Uses�timestamps,�so�nodes�need�to�maintain�synchronized�clocks.� � � ��������� • ���������� �for�each�principal� • Human�user’s�master�key�obtained�from�password� • Apps�have�(high2quality)�key� • Secret�key�K KDC �(not�shared�with�any�other�principal)� • for�encrypting�master�keys�in�local�database� • for�encrypting�TGTs� • Read2only�database�(except�when�principal�changes�master�key)� 5/7/2009�shankar� � � � � � authentication�slide�1� 5/7/2009�shankar� � � � � � authentication�slide�2� � � � � ������������������������ ���������������� • KDC�authenticates�user�based�on�user’s�master�key.� � • KDC�provides�user� ������������ (encrypted�with�master�key)�consisting�of� � user�A�(has�pw)� A’s�workstation� KDC�(has�A:�K A )� • ����������� �for�that�login�session�(user�master�key�is�not�used�after�login)� 1�start�login� � � • ����������������������������� used�to�obtain�further�tickets�from�KDC� send�[A,passwd]� TGT�is�encrypted�by�K KDC � 2� � send�[A,KDC,�AS_REQ]� � � � AS_REQ:�“A�needs�TGT”� ������������������������������������������������ receive�msg� � � • user’s�workstation�presents�KDC�with�[request,�TGT,�timestamp]�� retrieve�K A �� � generate�session�key�S A � (encrypted�with�session�key)� � tgt A � � �K KDC {A,�S A }� • KDC�returns� ����������� �(encrypted�with�session�key)�consisting�of�� � • session�key�(to�talk�to�application)� crd A � � �K A {S A ,�tgt A }�� � • ticket�for�application�(encrypted�with�application’s�master�key)� send�[KDC,�A,�AS_REP,�crd A� ]� 3� • user’s�workstation�presents�application�with�[request,�ticket]� � � � receive�msg� � � construct�K A �from�passwd� � extract�S A ,�tgt A �from�crd A � � forget�passwd;�� 4� ����shell�uses�S A �henceforth� � finish�login�� � � � � � � 5/7/2009�shankar� � � � � � authentication�slide�3� 5/7/2009�shankar� � � � � � authentication�slide�4� � �

� ��������������������������� ������������������������&�����'�������� � � ��!��"#��$!��!��"%#�� � � A� A’s�workstation� � • One�master�KDC�and�several�secondary�KDCs�� 1� rlogin�B� � � • Each�secondary�KDC�has�read2only�copy�of�KDC�database� 2� � send�[A,KDC,TGS_REQ,� � • Additions/deletions/changes�to�master�keys�always�done�at�master�KDC� “A�to�talk�to�B”,�tgt A ,�S A (ts)]� • Secondary�KDCs�can�generate�session�keys,�TGTs,�etc.� ▪ S A (ts):�authenticator�� • Master�disseminates�KDC�databases�to�secondary�KDCs�with�integrity� � � � receive�msg� protection�only�(but�master�keys�are�encrypted�with�K KDC )� � � generate�session�key�K AB � � � get�S A �from�tgt A � � � get�ts�and�verify� � � find�B’s�master�key�K B � � tkt B� ← �K B {A,�K AB }� � crd B �=�S A {B,K AB ,tkt B }� � �����//�credential� 3� send�[TGS_REP,�crd B ]�to�A� � � receive�msg�from�KDC� � 4� send�[A,B,�AP_REQ,�tkt B ,�K AB {ts}]� B� 5� � � send�[B,A,�AP_REP,�K AB {ts+1}�]� 6� � receive�msg� � � end�� � � 5/7/2009�shankar� � � � � � authentication�slide�5� 5/7/2009�shankar� � � � � � authentication�slide�6� � � � � �������������������������������������� ����&����������(��� • Possible�if�their�KDCs�share�a�key.� If�A�has�a�ticket�to�B�and�B�changes�its�password,�then�ticket�no�longer�valid.�� • Principal�name�=�[name,�instance,�realm],�each�string�of�40�chars�max� To�handle�this�case�(without�A�having�to�ask�KDC�for�a�new�ticket):� � • Applications�remember�old�master�keys�(up�to�expiry�time�(approx�21�hrs)� • In�tickets,�the�key�is�sent�along�with�version�number� A�in�realm�X� KDC X � KDC Y � B�in�realm�Y � • Human�users�need�not�remember�old�passwords� send�[A,�KDC X ,�TGS_REQ,�A.X,�D.Y]�� � � � #�������������������������������� receive�msg� � send�[KDC X ,�A,�TGS_REP,�cred�to�KDC Y ]�� � • Every�ticket�has�the�IPv4�address�of�the�principal�given�the�ticket� • Received�ticket�is�not�accepted�if�ticket�sender’s�IP�address�does�not�match� receive�msg� • So�if�B�is�to�impersonate�A,�it�must�also�spoof�the�IP�address�of�A�(easy�to�do)� send�[A,�KDC Y ,�TGS_REQ,�A.X,�B.Y,�cred]� • Prevents�delegation� receive�msg� • A�cannot�ask�B�at�another�IP�address�to�do�work�on�behalf�of�A�� � send�[KDC Y ,�A,�TGS_REP,�cred�to�B]� (unless�B�spoofs�IP�address�of�A!)� receive�msg� � send�[A,�B,�AP_REQ,�cred,�…]�� � receive�msg� � 5/7/2009�shankar� � � � � � authentication�slide�7� 5/7/2009�shankar� � � � � � authentication�slide�8� � �