[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SAML/Kerberos CMU use case (notes)
Folks, Here are my notes from today's discussion (Jeffery Hutzelman, Russ and Josh) regarding the CMU use-case for the Kerberos Attribute profile. (1) CMU use-case: The CMU use-case is summarized in the attached PNG file, in particular flows (3) and (4). Flows (1) and (2) represents the usual scenario where the client authenticates itself to the IdP and then seeks access to the Kerberized IMAP server through the SP. In this use case there is a further requirement in which the SP must be able to query the IdP to obtain (from the IdP/KDC) a KRB_CRED structure (an opaque blob). See below for the RFC4120 definition of the cred structure. The purpose of the KRB-CRED here is to support the scenario in which the SP has been asked by the client/user to access the IMAP server on behalf of (in the person of) the client/user. Thus the SP has to obtain a ticket from the IdP/KDC in which the named Client-Principal is the client but the named Service-Principal is the IMAP server (not the SP as it is usually the case with the browser SSO use-cases). How (i) the IdP obtains from the KDC a new service ticket and (ii) how the IdP/KDC creates the KRB-CRED structure is out of scope for the Oasis SAML2.0 Kerberos Attribute profile. Additionally, the release policy at the IdP (ie. which info the IdP releases to the SP upon query based on a client principal name) is out of scope for the Attribute profile. There is an additional requirement for confidentiality of transport of the KRB-CRED structure between the IdP and SP. How the IdP and SP negotiate/arrives at the cipher type and key(s) to be used need further thought (ie. should it be part of the Attribute profile?). (2) Proposed addition to the SAML2.0 Kerberos Attribute profile: The SAML2.0 Kerberos Attribute profile is defined in the following: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-kerberos-cd-01.pdf The profile already supports the case where the SP queries the IdP (using the SAML Request/Response) for a AP_REQ message. Thus, allowing for a different Kerberos structure (KRB-CRED) structure should be readily supportable. Here is an example of the Attribute request/response: [a] A SAML requester issues a request to a SAML attribute authority for a Kerberos KRB-CRED: <saml:Attribute xmlns:kerberos="urn:oasis:names:tc:SAML:2.0:attribute:kerberos" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:2.0:profiles:attribute:kerberos:KRB-CRED"> <------ <saml:AttributeValue> <kerberos:KerberosData> <kerberos:KerberosCname> joe@EXAMPLE.ORG </kerberos:KerberosCname> <----- client <kerberos:KerberosSname> IMAP@EXAMPLE.ORG <----- desired service </kerberos:KerberosSname> </kerberos:KerberosData> </saml:AttributeValue> </saml:Attribute> [b] A SAML attribute authority returns a Kerberos KRB-CRED opaque blob: <saml:Attribute xmlns:kerberos="urn:oasis:names:tc:SAML:2.0:attribute:kerberos" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:2.0:profiles:attribute:kerberos:KRB-CRED" <----- <saml:AttributeValue> <kerberos:KerberosData> <kerberos:KerberosCname> joe@EXAMPLE.ORG </kerberos:KerberosCname> <kerberos:KerberosSname> IMAP@EXAMPLE.ORG <--------- </kerberos:KerberosSname> <kerberos:KerberosMessage KerberosMsgType=”KRB-CRED”> <------- ...base64 representation of an KRB-CRED message... </kerberos:Message> </kerberos:KerberosData> </saml:AttributeValue> </saml:Attribute> (3) The Kerberos KRB-CRED structure: fyi. The KRB-CRED structure is defined in RFC4120 in Section 5.8. (p. 129) http://www.ietf.org/rfc/rfc4120.txt KRB-CRED ::= [APPLICATION 22] SEQUENCE { pvno [0] INTEGER (5), msg-type [1] INTEGER (22), tickets [2] SEQUENCE OF Ticket, enc-part [3] EncryptedData -- EncKrbCredPart } EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { ticket-info [0] SEQUENCE OF KrbCredInfo, nonce [1] UInt32 OPTIONAL, timestamp [2] KerberosTime OPTIONAL, usec [3] Microseconds OPTIONAL, s-address [4] HostAddress OPTIONAL, r-address [5] HostAddress OPTIONAL } KrbCredInfo ::= SEQUENCE { key [0] EncryptionKey, prealm [1] Realm OPTIONAL, pname [2] PrincipalName OPTIONAL, flags [3] TicketFlags OPTIONAL, authtime [4] KerberosTime OPTIONAL, starttime [5] KerberosTime OPTIONAL, endtime [6] KerberosTime OPTIONAL, renew-till [7] KerberosTime OPTIONAL, srealm [8] Realm OPTIONAL, sname [9] PrincipalName OPTIONAL, caddr [10] HostAddresses OPTIONAL } Note that the full KRB-CRED will be an opaque (encrypted) blob when it is delivered in the Attribute response message from the IdP to the SP. There is an open question as to whether some of the less-sensitive fields (eg. pvno - protocol version number) of the KRB-CRED could be copied out into the SAML Attribute response to help the SP. (4) Update is needed for Kerberos section in SAML2.0 Core specification (sect 8.3.5) Section 8.3.5 of the SAML2.0 Core Specifications is very short on Kerberos. This is what it reads today: 8.3.5 Kerberos Principal Name URI: urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos Indicates that the content of the element is in the form of a Kerberos principal name using the format name[/instance]@REALM. The syntax, format and characters allowed for the name, instance, and realm are described in IETF RFC 1510 [RFC 1510]. RFC1510 has been obsoleted by RFC4120. Additionally, Jeff notes that the naming syntax used for Kerberos should follow RFC1964. Thus at the very least all SAML2.0 specification referring to the Kerberos naming syntax should point to this RFC1964. http://www.ietf.org/rfc/rfc1964.txt AI: Thomas/Josh to recommend a small Eratta for the SAML Core to the SSTC. _______________________
saml-kerberos-cmu-use-case.png
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]