home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / kerberos / 980 < prev    next >
Encoding:
Text File  |  1993-01-01  |  2.4 KB  |  63 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!math.fu-berlin.de!uniol!Christian.Kuehnke
  3. From: Christian.Kuehnke@arbi.informatik.uni-oldenburg.de (Christian Kuehnke)
  4. Subject: V5: Inter-Realm-Authentication
  5. Organization: University of Oldenburg, Germany
  6. Date: Fri, 1 Jan 1993 23:20:22 GMT
  7. Message-ID: <1993Jan1.232124.28836@arbi.Informatik.Uni-Oldenburg.DE>
  8. Sender: news@arbi.Informatik.Uni-Oldenburg.DE
  9. Lines: 52
  10.  
  11. Hi!
  12.  
  13. I've got a question regarding inter-realm authentication in
  14. Kerberos V5. I think the "Internet-Draft" leaves some gaps open in
  15. this field.
  16.  
  17. Situation:     Client c in Realm rc wants to communicate with
  18.                Server s in Realm rs.
  19.  
  20. Now, I see two possibilities:
  21.  
  22. a)   c requests from his TGS a TGT for Realm rs
  23. b)   c requests from his TGS a Ticket for (s,rs)
  24.  
  25. Which one is the proper procedure? Assume that no interaction with
  26. intermediate Realms is necessary. In both of these cases, the
  27. response would be the same: A TGT for Realm rs, with which the
  28. client could request a Ticket for s from the remote TGS. Right?
  29.  
  30. Of course, in case b) the client would have to recognize, that the
  31. obtained Ticket isn't for s. On the other hand, in a) the client
  32. has to see that it simply cannot obtain the Ticket for s directly.
  33.  
  34. I am still more confused by page 24, section 5.3.1 of the Internet-
  35. Draft (01/09/92), where in the explanation of the "realm" field in
  36. the Ticket, it says:
  37.  
  38.      "This field specifies the realm that issued a ticket. It also
  39.      serves to identify the realm part of the servers's principal
  40.      identifier. Since a Kerberos server can only issue tickets for
  41.      servers within its realm, the two will always be identical."
  42.  
  43. But what does a TGT for a "remote" Realm then look like? Of course,
  44. the statement holds for Tickets for application servers. But for
  45. the example given above, shouldn't be realm=rs, sname=s?
  46. Especially, because in the pseudocode for KRB_TGS_REP generation
  47. (A.6), the realm of the resulting ticket always is set to the realm
  48. the TGT is for.
  49.  
  50. And the pseudocode for KRB_TGS_REQ generation (A.5) doesn't set
  51. req.realm at all...
  52.  
  53. Any enlightening is very much appreciated :-)
  54.  
  55. Happy new year,
  56. Christian
  57.  
  58. -- 
  59. - Snail   : Christian Kuehnke/Hartenscher Damm 65/2900 Oldenburg/BRD -
  60. - Internet: Christian.Kuehnke@arbi.Informatik.Uni-Oldenburg.DE       -
  61. - Bitnet  :            249923@DOLUNI1                                -
  62. <* For CIA grep: bomb, spy, attack, socialism, panama, cuba, grenada *>
  63.