[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss-comment] Comments on the WSS Kerberos Token Profile 1.0, Draft 5
Comments in line
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Nicolas Williams <Nicolas.Williams@sun.com> wrote on 04/14/2005 04:35:22 PM:
> The Web Services Security Kerberos Token Profile 1.0, Draft 5 appears,
> in some ways to be incomplete.
Not sure what you mean by incomplete, it seems Kerberos
is also incomplete according to lots of folks. So incomplete would be based
on what the original goals were.
>
> Additionally, I believe it is quite unfortunate that the Kerberos V
> GSS-API mechanism was not used instead. I can understand that the lack
> of a keying facility may well have led to this unfortunate design, but
> you should know that the IETF KITTEN WG is currently holding a Working
> Group Last call on a GSS-API extension for (and corresponding Kerberos V
> mechanism specification of) a pseudo-random function keyed internally by
> a GSS-API security context. This new feature of both, the GSS-API and
> the Kerberos V GSS-API mechanism should provide all the functionality
> needed by OASIS for a profile such as the one I'm commenting on.
Not everyone uses GSS, if your asking to add GSS support then that's reasonable
but to say the design is unfortunate is confusing as you also point out
the issues that we ran into when we considered using GSS, its not complete :-).
>
> Besides my above comment on the non-use of the GSS-API, I have the
> following comments on Draft 5 of the profile:
>
> - Naming
>
> There is nothing in the profile about Kerberos V principal naming.
>
> What kind of service principal names should be used?
>
> Or is this to be specified by applications that use this profile?
>
> If so then this should be pointed out. But since this profile seems
> to be closely connected with SOAP I suspect that naming
> considerations need to be discussed in the profile.
Not sure why you think that this should address principal naming ?
>
> Are non-Kerberos names to be mapped to Kerberos V principal names?
> If so, how, or where is this specified?
>
Why would this be the responsibility of the spec to tell you how to do the
mapping ?
>
> - Session key negotiation and key re-use
>
> The profile should say whether or not the optional sub-session key in
> the AP-REQ's Authenticator MAY/SHOULD/MUST be present/absent, which
> of the Ticket's or Authenticator's session key "wins" when the
> Authenticator asserts a sub-session key.
Why ? this could be used with session or sub session keys, it would either be
a policy or a profile to narrow this down for interop. So in the current
interop we are using the session key, we could have chosen the sub-session
key, either are valid.
>
> Assertion of sub-session keys in Authenticators is an excellent
> approach to key re-use prevention. I'll have to review the other WSS
> specifications and drafts (and probably SOAP as well) to get a good
> idea of whether key re-use is prevented elsewhere.
As I said this can be a choice depending on the scenario
>
> I suppose, though I will have to review the other WSS and related W3C
> specs/drafts to be sure of it, that proper key derivation is done
> elsewhere. It would be useful, to readers not familiar with OASIS
> specifications, to mention where key derivation happens, along with
> references.
>
>
> - Replay protection and mutual authentication
>
> This profile says little about replay protection and nothing about
> mutual authentication. While it may be sensible to leave replay
> protection to the "mechanisms described in WS-Security" I get the
> impression from the text in section 4 that there are special
> considerations related to this particular profile, yet no
> RFC2119 terminology (MAY/SHOULD/MUST/...) is used to indicate what,
> if anything, implementors should do.
>
> As for mutual authentication, if the "mechanisms described in
> WS-Security" provide it, then that should be explained in the
> profile, just as with replay protection.
The concept here is that you be familiar with the core specification
so we can refer the reader back to the core.
>
>
> - Error handling
>
> This profile does not make use of the KRB-ERROR Kerberos V PDU, nor
> does it mention any Kerberos V error codes. Instead it refers to
> error codes "defined in the WS-Security specification" without giving
> any indication of how Kerberos V error conditions on the server
> (acceptor) side should be mapped to WSS errors, if at all.
Correct this is true of other profiles that we have done.
>
>
> - Channel binding
>
> Section 4, last paragraph (lines 214-215) says "It should be noted
> that transport-level security MAY be used to protect the message and
> the security token." I think this needs some clarification.
>
> Why should the AP-REQ message require additional protection from
> lower layers? From what sorts of attacks? What if no such
> protection is available? Shouldn't the session key from the AP-REQ
> be used to provide integrity protection to the S11 header?
>
> Or is this text indicating, obliquely I suppose, that it is possible
> to use this profile for authentication but rely on lower network
> layers for session protection?
>
> If the latter, note that there is a channel binding problem in that
> more normative text is needed to ensure that the end-points of the
> lower-layer channel and the application layer are effectively the
> same, else MITM attacks may be possible. [Note: I assume that the
> "transport-level security" is secure against MITM attacks, but MITM
> attacks may be feasible nonetheless by misdirecting the
> system/application so that one layer or the other it is speaking to
> an otherwise properly authenticated attacked.] This can be avoided
> with some additional requirements.
>
>
> - Normative references to soon-to-be-obsoleted documents
>
> RFC1510 will be obsoleted as soon as the RFC-Editor publishes
>
> draft-ietf-krb-wg-kerberos-clarifications-07.txt
>
> as an RFC. That Internet-Draft has already been approved as a
> Proposed Standard by the IESG.
Will update as appropriate
>
> The WSS Kerberos Token Profile should be reviewed with kerberos-
> clarifications in mind and, if it should not progress from Draft
> status prior to the publication of kerberos-clarifications as an RFC,
> then it should be changed to list the new RFC as a normative
> reference for the Kerberos Network Authentication Service (V5).
Why ? Are you saying no one should do anything with Kerberos until
this is complete ?
>
>
> - General silliness
>
> Section 3.5 says that "[when] a Kerberos ticket is referenced as an
> encryption key, the encryption algorithm MUST be a symmetric
> encryption algorithm." At first glance this would seem self-evident
> given the normative reference to RFC1510, but since the encryption in
> question is not based on Kerberos specifications this is not so
> obvious, which leads me to ask...
>
> ...why not say the same thing in section 3.4?
Do we need to duplicate ? If so will put a reference in 3.4
>
> Also, section 2.3 lists terms not used anywhere else in the document,
> such as 'UCS' and 'UTF-8'. Is the document incomplete, perhaps with
> regards to internationalization (I18N)? Note that Kerberos V
> currently can only be interoperably used where principal and realm
> names are limited to US-ASCII characters (the IETF KRB WG is working
> on properly internationalizing the protocol).
Could be incomplete relative to a lot of things since I don't know what
your definition of complete is. So what are you looking for here, term
definitions ?
>
>
> Finally, I will give the IETF KRB and KITTEN WGs a heads-up about this
> OASIS profile, as their participants may not be aware of this profile
> and may wish to review and comment on it.
Thank you taking the time to review and comment.
>
> Cheers,
>
> Nico
> --
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]