[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]
